On 5/1/2025 9:40 PM, dbush wrote:
On 5/1/2025 10:34 PM, olcott wrote:
On 5/1/2025 8:58 PM, André G. Isaak wrote:
On 2025-05-01 19:09, olcott wrote:
On 5/1/2025 7:32 PM, André G. Isaak wrote:
On 2025-05-01 14:15, olcott wrote:
On 5/1/2025 10:14 AM, André G. Isaak wrote:
On 2025-04-30 21:50, olcott wrote:
On 4/30/2025 7:17 PM, André G. Isaak wrote:
You are still hopelessly confused about your terminology.
Computable functions are a subset of mathematical
functions, and mathematical functions are *not* the
same thing as C functions. Functions do not apply
"transformations". They are simply mappings, and a
functions which maps every pair of natural numbers to 5
is a perfectly legitimate, albeit not very interesting,
function.
What makes this function a *computable function* is
that fact that it is possible to construct a C function
(or a Turing Machine, or some other type of algorithm)
such as int foo(int x, int y) {return 5;} which
computes that particular function; but the C function
and the computable function it computes are entirely
separate entities.
computes the sum of two integers
by transforming the inputs into an output.
int sum(int x, int y) { return x + y; }
Computes no function because it ignores its inputs.
int sum(int x, int y) { return 5; }
All you're demonstrating here is that you have no clue
what a function is, nor, apparently, do you have any
desire to learn.
André
What I am explaining is that a halt decider
must compute the mapping FROM THE INPUTS ONLY
by applying a specific set of finite string
transformations to the inputs.
No. Halt deciders weren't even mentioned above. I was
addressing your absurd claim that int foo(int x, int y) {
return 5; } does not compute a function. This clearly
indicates that you do not grasp the concept of "function".
This is a brand new elaboration of computer
science that I just came up with.
IOW something you've pulled out of your ass.
It is common knowledge THAT inputs must correspond
to OUTPUTS. What is totally unknown and brand new
created by me is HOW inputs are made to correspond
to OUTPUTS.
We were discussing functions. Functions don't have inputs or
outputs; they have domains and codomains. ALGORITHMS have
inputs and outputs, and you keep conflating the two.
Specific finite string transformation rules are
applied to inputs to derive outputs.
Please point to a definition of 'function' which mentions
"finite string transformation rules". This may be a useful
way of viewing some (but certainly not all) algorithms, but
it has nothing to do with functions. Functions are simply a
mapping from one set (the domain) to another set (the
codomain) such that every element of the domain maps to one
and only one element of the codomain.
What everyone else has been doing is simply GUESSING
that they correspond or relying on some authority
that say they must correspond. (Appeal to authority error).
This is another baseless assertion that you've simply pulled
out of your ass. If you think otherwise, please provide a
concrete example
DD correctly emulated by HHH maps to NON-HALTING BEHAVIOR.
It really does, all that you have to do is PAY ATTENTION.
Whether DD emulated by HH maps to halting or non-halting
behaviour is entirely dependent on which function is being
computed.
André
We are computing the halt function
i.e. this function:
Given any algorithm (i.e. a fixed immutable sequence of
instructions) X described as <X> with input Y:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when
executed directly
Which has been proven to be uncomputable, as shown by Linz and
as you have *explicitly* agreed is correct.
FOR THE INPUT NOT ANY DAMN THING ELSE
FOR THE INPUT NOT ANY DAMN THING ELSE
FOR THE INPUT NOT ANY DAMN THING ELSE
FOR THE INPUT NOT ANY DAMN THING ELSE
FINITE STRING TRANSFORMATIONS OF THE INPUT ELSE WRONG
FINITE STRING TRANSFORMATIONS OF THE INPUT ELSE WRONG
FINITE STRING TRANSFORMATIONS OF THE INPUT ELSE WRONG
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
Replacing the code of HHH with an unconditional simulator and
subsequently running HHH(DD) specifies recursive
simulation such that DD cannot possibly reach its
"return instruction" (final halt state). Thus HHH
is correct to reject DD as non halting.
So you changed the input. Changing the input is not allowed.
I never changed the input.
On 5/1/2025 11:57 PM, olcott wrote:
On 5/1/2025 9:40 PM, dbush wrote:
So you changed the input. Changing the input is not allowed.
I never changed the input.
Yes you did. You hypothesize changing the code of HHH, and HHH
is part of the input. So you changed the input.
Changing the input is not allowed.
the answers it has been providing for over a decade, thousands ofchanges the input<<< in some small way. Does that invalidate
On 5/1/2025 9:40 PM, dbush wrote:
On 5/1/2025 10:34 PM, olcott wrote:
On 5/1/2025 8:58 PM, André G. Isaak wrote:
On 2025-05-01 19:09, olcott wrote:
On 5/1/2025 7:32 PM, André G. Isaak wrote:
On 2025-05-01 14:15, olcott wrote:
On 5/1/2025 10:14 AM, André G. Isaak wrote:
On 2025-04-30 21:50, olcott wrote:
On 4/30/2025 7:17 PM, André G. Isaak wrote:
You are still hopelessly confused about your terminology.
Computable functions are a subset of mathematical functions, >>>>>>>>>> and mathematical functions are *not* the same thing as C
functions. Functions do not apply "transformations". They are >>>>>>>>>> simply mappings, and a functions which maps every pair of
natural numbers to 5 is a perfectly legitimate, albeit not >>>>>>>>>> very interesting, function.
What makes this function a *computable function* is that fact >>>>>>>>>> that it is possible to construct a C function (or a Turing >>>>>>>>>> Machine, or some other type of algorithm) such as int foo(int >>>>>>>>>> x, int y) {return 5;} which computes that particular function; >>>>>>>>>> but the C function and the computable function it computes are >>>>>>>>>> entirely separate entities.
computes the sum of two integers
by transforming the inputs into an output.
int sum(int x, int y) { return x + y; }
Computes no function because it ignores its inputs.
int sum(int x, int y) { return 5; }
All you're demonstrating here is that you have no clue what a
function is, nor, apparently, do you have any desire to learn. >>>>>>>>
André
What I am explaining is that a halt decider
must compute the mapping FROM THE INPUTS ONLY
by applying a specific set of finite string
transformations to the inputs.
No. Halt deciders weren't even mentioned above. I was addressing
your absurd claim that int foo(int x, int y) { return 5; } does
not compute a function. This clearly indicates that you do not
grasp the concept of "function".
This is a brand new elaboration of computer
science that I just came up with.
IOW something you've pulled out of your ass.
It is common knowledge THAT inputs must correspond
to OUTPUTS. What is totally unknown and brand new
created by me is HOW inputs are made to correspond
to OUTPUTS.
We were discussing functions. Functions don't have inputs or
outputs; they have domains and codomains. ALGORITHMS have inputs and
outputs, and you keep conflating the two.
Specific finite string transformation rules are
applied to inputs to derive outputs.
Please point to a definition of 'function' which mentions "finite
string transformation rules". This may be a useful way of viewing
some (but certainly not all) algorithms, but it has nothing to do
with functions. Functions are simply a mapping from one set (the
domain) to another set (the codomain) such that every element of the
domain maps to one and only one element of the codomain.
What everyone else has been doing is simply GUESSING
that they correspond or relying on some authority
that say they must correspond. (Appeal to authority error).
This is another baseless assertion that you've simply pulled out of
your ass. If you think otherwise, please provide a concrete example
DD correctly emulated by HHH maps to NON-HALTING BEHAVIOR.
It really does, all that you have to do is PAY ATTENTION.
Whether DD emulated by HH maps to halting or non-halting behaviour
is entirely dependent on which function is being computed.
André
We are computing the halt function
i.e. this function:
Given any algorithm (i.e. a fixed immutable sequence of instructions)
X described as <X> with input Y:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly
Which has been proven to be uncomputable, as shown by Linz and as you
have *explicitly* agreed is correct.
FOR THE INPUT NOT ANY DAMN THING ELSE
FOR THE INPUT NOT ANY DAMN THING ELSE
FOR THE INPUT NOT ANY DAMN THING ELSE
FOR THE INPUT NOT ANY DAMN THING ELSE
FINITE STRING TRANSFORMATIONS OF THE INPUT ELSE WRONG
FINITE STRING TRANSFORMATIONS OF THE INPUT ELSE WRONG
FINITE STRING TRANSFORMATIONS OF THE INPUT ELSE WRONG
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
Replacing the code of HHH with an unconditional simulator and
subsequently running HHH(DD) specifies recursive
simulation such that DD cannot possibly reach its
"return instruction" (final halt state). Thus HHH
is correct to reject DD as non halting.
So you changed the input. Changing the input is not allowed.
I never changed the input.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
    If simulating halt decider H correctly simulates its input D
    until H correctly determines that its simulated D would never
    stop running unless aborted then
    H can abort its simulation of D and correctly report that D
    specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
And *yet again* you lie by implying that Sipser agrees with you when
it's been proven *on multiple occasions* that he does not:
Professor Sipser gave me permission to quote
those words above Ben verified that too.
Assuming the those words are true I AM PROVED CORRECT.
Why would professor Sipser agree with words that are not true?
On Monday, March 6, 2023 at 2:41:27 PM UTC-5, Ben Bacarisse wrote:
I exchanged emails with him about this. He does not agree withanything
substantive that PO has written. I won't quote him, as I don't have
permission, but he was, let's say... forthright, in his reply to me.
Your dishonesty knows no bounds.
On 02/05/2025 05:08, dbush wrote:
On 5/1/2025 11:57 PM, olcott wrote:
On 5/1/2025 9:40 PM, dbush wrote:
<snip>
So you changed the input. Changing the input is not allowed.
I never changed the input.
Yes you did. You hypothesize changing the code of HHH, and HHH is part of the input. So you
changed the input.
Agreed.
Changing the input is not allowed.
Wweellll...
I have a very minor objection to that view, an objection that I've wrapped up into a thought
experiment.
Let us hypothesise the paradoxical existence of U, a universal decider. If we pass it an arbitrary P
and an arbitrary D, it can defy Turing (we're just hypothesising, remember) and produce a correct
result. Cool, right? The snag is that it's a black box. We can't see the code.
We set it to work, and for years we use it to prove all manner of questions - PvNP, Collatz,
Goldbach, Riemann, the lot - and it turns out always to be right. That's good, right?
But then one fine day in 2038 we are finally allowed to see the source code for U, which is when we
discover that the algorithm >>>changes the input<<< in some small way. Does that invalidate the
answers it has been providing for over a decade, thousands of answers that have /all/ been verified?
I would argue that it doesn't. Provided U(P,D) correctly reports on the behaviour a P(D) call would
produce, I would argue that that's all that matters, and the fact that U twiddles with the P and D
tapes and turns them into P' and D' is irrelevant, as long as the result we get is that of P(D), not
P'(D').
Let me show this graphically using a much simpler example - addition:
D: 1111111111+1111111
P: add 'em up
P(D)!
D': 11111111111111111
P has changed its input by changing the + to a 1 and erasing the last 1, and D' now holds the
correct answer to the question originally posed on D.
I would argue that this is /perfectly fine/, and that there is nothing in Turing's problem statement
to forbid it. But of course we must be careful that, even if U does change its inputs to P' and D',
it must still correctly answer the question P(D).
Of course, Mr Olcott's change is rather different, because by changing his HHH he's actually
changing the behaviour of his DD - i.e. specifying a new U - but I see no reason why he can't do
that /provided/ he can show that he always gets the correct answer. He has so far failed to do this
with the original HHH, and now he has doubled his workload by giving himself another HHH to defend.
For your point of view I could probably just have said "It's
bleedin' obvious that the input D can't be changed to D' (or
anything else) half way through interpreting Sipser's words".
Also probably that would be enough for you to get that your
interpretation of "changing the input" went down the wrong road...
I kind of disagree with your mild denigration of the Linz (and similar) proofs.
On 5/2/2025 8:16 PM, Mike Terry wrote:Still true.
On 02/05/2025 06:06, Richard Heathfield wrote:
On 02/05/2025 05:08, dbush wrote:
On 5/1/2025 11:57 PM, olcott wrote:
On 5/1/2025 9:40 PM, dbush wrote:
Agreed.Yes you did. You hypothesize changing the code of HHH, and HHH isSo you changed the input. Changing the input is not allowed.I never changed the input.
part of the input. So you changed the input.
Exactly, IF, but H is not an UTM but a simulator *that aborts* and returnsIn other words if embedded_H was a UTM would cause Ĥ applied to ⟨Ĥ⟩ to never halt then embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩Of course, Mr Olcott's change is rather different, because by changing
his HHH he's actually changing the behaviour of his DD - i.e.
specifying a new U - but I see no reason why he can't do that /
provided/ he can show that he always gets the correct answer. He has
so far failed to do this with the original HHH, and now he has doubled
his workload by giving himself another HHH to defend.
Right - PO's H is free to rewrite the tape in whatever way it likes,
provided in the end it gets the right answer.
The "you're not allowed to change the input" charge means something
quite different.
TLDR:Â Your talking about TMs writing to their tape as part of their
normal operation. Nothing wrong with that. PO is effectively talking
about changing the meaning of D [the input to H] half way through the
Sipser quote.
----------------------------------------------------------------------------- >> NTLFM:
PO is trying to interpret Sipser's quote:
--- Start Sipser quote
--- End Sipser quote
The following interpretation is ok:
   If H is given input D, and while simulating D gathers enough
   information to deduce that UTM(D) would never halt, then H can
   abort its simulation and decide D never halts.
is correctly ruled to never halt.
HHH determines whether or not DD would halt if HHH would have been aNobody cares about a non-input. In fact HHH is not a pure simulator
pure simulator.
ChatGPT DOES understand hypothetical possibilities and does understandOnly that is not what is asked of a halt decider.
that HHH computes the termination status of its input on the basis of
these hypothetical possibilities.
On 03/05/2025 02:16, Mike Terry wrote:
For your point of view I could probably just have said "It's bleedin' obvious that the input D
can't be changed to D' (or anything else) half way through interpreting Sipser's words".
Yes, that would cover it.
Also probably that would be enough for you to get that your interpretation of "changing the input"
went down the wrong road...
More than enough.
In passing, when I nailed down "TL;DR" I felt mildly guilty for scoring so few tersinosity points,
but in return I must accuse you of undue obscurity.
TL;DR appears to have attracted a certain currency, so okay, but... NTLFM? Really? "Seek and ye
shall find", so I sought but shall findethed not. Most of my best guesses started 'Now The' and
ended rhyming with RTFM, but none of those guesses jumped out as being self-evidently right. Would
you care to translate?
I kind of disagree with your mild denigration of the Linz (and similar) proofs.
I wish to clarify that denigration was most certainly not my intent. There is, however, no doubt in
my mind that while Linz is undoubtedly a worthy and indeed admirable computer scientist, his proof
stands on giant shoulders. All I meant to say was that, were Linz's proof to lose its balance and
take a tumble, it would not be the fault of the shoulders.
On 03/05/2025 06:47, Richard Heathfield wrote:
In passing, when I nailed down "TL;DR" I felt mildly guilty for
scoring so few tersinosity points, but in return I must accuse
you of undue obscurity.
TL;DR appears to have attracted a certain currency, so okay,
but... NTLFM? Really? "Seek and ye shall find", so I sought but
shall findethed not. Most of my best guesses started 'Now The'
and ended rhyming with RTFM, but none of those guesses jumped
out as being self-evidently right. Would you care to translate?
I admit to making it up, but all these (usenet?) abbreviations
have to start somewhere, so I thought I would start a much needed
new one!
TL;DR = too long, didn't read,
introducing a short summary for
someone who hasn't the inclination/time to read a long (probably
overly) verbose explanation. At least that's how I've seen it
used. But then, how to introduce the verbose explanation? I
couldn't find anything for that, so I invented NTLFM; which means
"Not Too Long For Me" !
I'm looking forward to being a footnote
in history when it catches on...
I kind of disagree with your mild denigration of the Linz (and
similar) proofs.
I wish to clarify that denigration was most certainly not my
intent. There is, however, no doubt in my mind that while Linz
is undoubtedly a worthy and indeed admirable computer
scientist, his proof stands on giant shoulders. All I meant to
say was that, were Linz's proof to lose its balance and take a
tumble, it would not be the fault of the shoulders.
Yeah, denigration was really the wrong word, as I know there was
no bad intent anywhere. Perhaps "downplaying" would have been
what I was looking for.
Ben pointed out there was confusion in the Linz proof with the
labelling of states, and when I looked closely at the proof I a
few years ago I recall thinking Linz had munged the conversion of
(general) TM tape inputs to "H inputs" (which in Linz are binary representations of those tapes) when duplicating D's input. Now
I'm not sure about that, but can't motivate myself to get to the
bottom of it, since either way, if it is a problem it's clear how
it should be fixed, and the basis for the proof is not affected.
The proof is both "very easy" conceptually [as witnessed by how
many people join in here, quickly understanding how it works if
they've not come across it before], and slightly fiddly due to
the TM H needing to have a fixed tape alphabet which must be able
to represent any TM as well as any tape input for that TM. So
there are certainly opportunities to miss details especially with
a book aimed at those with a minimal maths background. Really,
the only aspect of the proof requiring careful thought is
convincing yourself that the fiddliness has been handled ok,
along with understanding the notation used...
I don't see any scope for the proof actually being invalid, and
PO certainly does not present any argument for it being invalid.
He simply believes his H can give the right answer for his D, and
that's the beginning and end of it all. When he developed his
x96utm, it became possible to actually run his code, and it
became /manifestly/ clear his H gets the wrong answer for D. But
PO just doubles down and comes up with bizarre explanations for
why he still thinks it is right when it is obviously wrong.
On 5/2/2025 8:16 PM, Mike Terry wrote:..if H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
On 02/05/2025 06:06, Richard Heathfield wrote:
On 02/05/2025 05:08, dbush wrote:
On 5/1/2025 11:57 PM, olcott wrote:
On 5/1/2025 9:40 PM, dbush wrote:
<snip>
So you changed the input. Changing the input is not allowed.
I never changed the input.
Yes you did. You hypothesize changing the code of HHH, and HHH is part of the input. So you
changed the input.
Agreed.
Changing the input is not allowed.
Wweellll...
I have a very minor objection to that view, an objection that I've wrapped up into a thought
experiment.
Let us hypothesise the paradoxical existence of U, a universal decider. If we pass it an
arbitrary P and an arbitrary D, it can defy Turing (we're just hypothesising, remember) and
produce a correct result. Cool, right? The snag is that it's a black box. We can't see the code.
We set it to work, and for years we use it to prove all manner of questions - PvNP, Collatz,
Goldbach, Riemann, the lot - and it turns out always to be right. That's good, right?
But then one fine day in 2038 we are finally allowed to see the source code for U, which is when
we discover that the algorithm >>>changes the input<<< in some small way. Does that invalidate
the answers it has been providing for over a decade, thousands of answers that have / all/ been
verified?
Nobody would suggest that TMs aren't allowed to write to their tape! Of course, that's part of
how they work, and is not what posters mean by PO "changing the input".
I would argue that it doesn't. Provided U(P,D) correctly reports on the behaviour a P(D) call
would produce, I would argue that that's all that matters, and the fact that U twiddles with the
P and D tapes and turns them into P' and D' is irrelevant, as long as the result we get is that
of P(D), not P'(D').
Right. What you're describing is business as usual for TMs.
Let me show this graphically using a much simpler example - addition:
D: 1111111111+1111111
P: add 'em up
P(D)!
D': 11111111111111111
P has changed its input by changing the + to a 1 and erasing the last 1, and D' now holds the
correct answer to the question originally posed on D.
I would argue that this is /perfectly fine/, and that there is nothing in Turing's problem
statement to forbid it. But of course we must be careful that, even if U does change its inputs
to P' and D', it must still correctly answer the question P(D).
Nothing wrong with that.
BTW all the stuff above about universal deciders turns out to be irrelevant to your argument! (It
just seems a bit odd to choose a non- existant TM as an example when any other (existant) TM would
do the job more clearly...)
Of course, Mr Olcott's change is rather different, because by changing his HHH he's actually
changing the behaviour of his DD - i.e. specifying a new U - but I see no reason why he can't do
that / provided/ he can show that he always gets the correct answer. He has so far failed to do
this with the original HHH, and now he has doubled his workload by giving himself another HHH to
defend.
Right - PO's H is free to rewrite the tape in whatever way it likes, provided in the end it gets
the right answer.
The "you're not allowed to change the input" charge means something quite different.
TLDR: Your talking about TMs writing to their tape as part of their normal operation. Nothing
wrong with that. PO is effectively talking about changing the meaning of D [the input to H] half
way through the Sipser quote.
-----------------------------------------------------------------------------
NTLFM:
PO is trying to interpret Sipser's quote:
--- Start Sipser quote
     If simulating halt decider H correctly simulates its input D
     until H correctly determines that its simulated D would never
     stop running unless aborted then
     H can abort its simulation of D and correctly report that D
     specifies a non-halting sequence of configurations.
--- End Sipser quote
The following interpretation is ok:
    If H is given input D, and while simulating D gathers enough
    information to deduce that UTM(D) would never halt, then
    H can abort its simulation and decide D never halts.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn..if H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(g) goto (d) with one more level of simulation
In other words if embedded_H was a UTM would cause
Ĥ applied to ⟨Ĥ⟩ to never halt then embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
is correctly ruled to never halt.
The following interpretation is ok:
If H is given input D, and while simulating D gathers enough
information to deduce that UTM(D) would never halt, then
H can abort its simulation and decide D never halts.
if embedded_H is given input ⟨Ĥ⟩ ⟨Ĥ⟩, and while simulating Ĥ gathers enough
information to deduce that UTM(⟨Ĥ⟩ ⟨Ĥ⟩) would never halt, then
embedded_H can abort its simulation and decide Ĥ [run with input Ĥ]
never halts.
On 5/2/2025 8:16 PM, Mike Terry wrote:
On 02/05/2025 06:06, Richard Heathfield wrote:
On 02/05/2025 05:08, dbush wrote:
On 5/1/2025 11:57 PM, olcott wrote:
On 5/1/2025 9:40 PM, dbush wrote:
<snip>
So you changed the input. Changing the input is not allowed.
I never changed the input.
Yes you did. You hypothesize changing the code of HHH, and HHH is
part of the input. So you changed the input.
Agreed.
Changing the input is not allowed.
Wweellll...
I have a very minor objection to that view, an objection that I've
wrapped up into a thought experiment.
Let us hypothesise the paradoxical existence of U, a universal
decider. If we pass it an arbitrary P and an arbitrary D, it can defy
Turing (we're just hypothesising, remember) and produce a correct
result. Cool, right? The snag is that it's a black box. We can't see
the code.
We set it to work, and for years we use it to prove all manner of
questions - PvNP, Collatz, Goldbach, Riemann, the lot - and it turns
out always to be right. That's good, right?
But then one fine day in 2038 we are finally allowed to see the
source code for U, which is when we discover that the algorithm
answers it has been providing for over a decade, thousands of answerschanges the input<<< in some small way. Does that invalidate the
that have / all/ been verified?
Nobody would suggest that TMs aren't allowed to write to their tape!
Of course, that's part of how they work, and is not what posters mean
by PO "changing the input".
I would argue that it doesn't. Provided U(P,D) correctly reports on
the behaviour a P(D) call would produce, I would argue that that's
all that matters, and the fact that U twiddles with the P and D tapes
and turns them into P' and D' is irrelevant, as long as the result we
get is that of P(D), not P'(D').
Right. What you're describing is business as usual for TMs.
Let me show this graphically using a much simpler example - addition:
D: 1111111111+1111111
P: add 'em up
P(D)!
D': 11111111111111111
P has changed its input by changing the + to a 1 and erasing the last
1, and D' now holds the correct answer to the question originally
posed on D.
I would argue that this is /perfectly fine/, and that there is
nothing in Turing's problem statement to forbid it. But of course we
must be careful that, even if U does change its inputs to P' and D',
it must still correctly answer the question P(D).
Nothing wrong with that.
BTW all the stuff above about universal deciders turns out to be
irrelevant to your argument! (It just seems a bit odd to choose a
non- existant TM as an example when any other (existant) TM would do
the job more clearly...)
Of course, Mr Olcott's change is rather different, because by
changing his HHH he's actually changing the behaviour of his DD -
i.e. specifying a new U - but I see no reason why he can't do that /
provided/ he can show that he always gets the correct answer. He has
so far failed to do this with the original HHH, and now he has
doubled his workload by giving himself another HHH to defend.
Right - PO's H is free to rewrite the tape in whatever way it likes,
provided in the end it gets the right answer.
The "you're not allowed to change the input" charge means something
quite different.
TLDR:Â Your talking about TMs writing to their tape as part of their
normal operation. Nothing wrong with that. PO is effectively talking
about changing the meaning of D [the input to H] half way through the
Sipser quote.
-----------------------------------------------------------------------------
NTLFM:
PO is trying to interpret Sipser's quote:
--- Start Sipser quote
     If simulating halt decider H correctly simulates its input D
     until H correctly determines that its simulated D would never
     stop running unless aborted then
     H can abort its simulation of D and correctly report that D
     specifies a non-halting sequence of configurations.
--- End Sipser quote
The following interpretation is ok:
    If H is given input D, and while simulating D gathers enough
    information to deduce that UTM(D) would never halt, then
    H can abort its simulation and decide D never halts.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(g) goto (d) with one more level of simulation
In other words if embedded_H was a UTM would cause
Ĥ applied to ⟨Ĥ⟩ to never halt then embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
is correctly ruled to never halt.
On 5/2/2025 8:16 PM, Mike Terry wrote:
On 02/05/2025 06:06, Richard Heathfield wrote:
On 02/05/2025 05:08, dbush wrote:
On 5/1/2025 11:57 PM, olcott wrote:
On 5/1/2025 9:40 PM, dbush wrote:
<snip>
So you changed the input. Changing the input is not allowed.
I never changed the input.
Yes you did. You hypothesize changing the code of HHH, and HHH is
part of the input. So you changed the input.
Agreed.
Changing the input is not allowed.
Wweellll...
I have a very minor objection to that view, an objection that I've
wrapped up into a thought experiment.
Let us hypothesise the paradoxical existence of U, a universal
decider. If we pass it an arbitrary P and an arbitrary D, it can defy
Turing (we're just hypothesising, remember) and produce a correct
result. Cool, right? The snag is that it's a black box. We can't see
the code.
We set it to work, and for years we use it to prove all manner of
questions - PvNP, Collatz, Goldbach, Riemann, the lot - and it turns
out always to be right. That's good, right?
But then one fine day in 2038 we are finally allowed to see the
source code for U, which is when we discover that the algorithm
answers it has been providing for over a decade, thousands of answerschanges the input<<< in some small way. Does that invalidate the
that have / all/ been verified?
Nobody would suggest that TMs aren't allowed to write to their tape!
Of course, that's part of how they work, and is not what posters mean
by PO "changing the input".
I would argue that it doesn't. Provided U(P,D) correctly reports on
the behaviour a P(D) call would produce, I would argue that that's
all that matters, and the fact that U twiddles with the P and D tapes
and turns them into P' and D' is irrelevant, as long as the result we
get is that of P(D), not P'(D').
Right. What you're describing is business as usual for TMs.
Let me show this graphically using a much simpler example - addition:
D: 1111111111+1111111
P: add 'em up
P(D)!
D': 11111111111111111
P has changed its input by changing the + to a 1 and erasing the last
1, and D' now holds the correct answer to the question originally
posed on D.
I would argue that this is /perfectly fine/, and that there is
nothing in Turing's problem statement to forbid it. But of course we
must be careful that, even if U does change its inputs to P' and D',
it must still correctly answer the question P(D).
Nothing wrong with that.
BTW all the stuff above about universal deciders turns out to be
irrelevant to your argument! (It just seems a bit odd to choose a
non- existant TM as an example when any other (existant) TM would do
the job more clearly...)
Of course, Mr Olcott's change is rather different, because by
changing his HHH he's actually changing the behaviour of his DD -
i.e. specifying a new U - but I see no reason why he can't do that /
provided/ he can show that he always gets the correct answer. He has
so far failed to do this with the original HHH, and now he has
doubled his workload by giving himself another HHH to defend.
Right - PO's H is free to rewrite the tape in whatever way it likes,
provided in the end it gets the right answer.
The "you're not allowed to change the input" charge means something
quite different.
TLDR:Â Your talking about TMs writing to their tape as part of their
normal operation. Nothing wrong with that. PO is effectively talking
about changing the meaning of D [the input to H] half way through the
Sipser quote.
-----------------------------------------------------------------------------
NTLFM:
PO is trying to interpret Sipser's quote:
--- Start Sipser quote
     If simulating halt decider H correctly simulates its input D
     until H correctly determines that its simulated D would never
     stop running unless aborted then
     H can abort its simulation of D and correctly report that D
     specifies a non-halting sequence of configurations.
--- End Sipser quote
The following interpretation is ok:
    If H is given input D, and while simulating D gathers enough
    information to deduce that UTM(D) would never halt, then
    H can abort its simulation and decide D never halts.
That is the same way that ChatGPT understands it.
*ChatGPT Analyzes Simulating Termination Analyzer* https://www.researchgate.net/ publication/385090708_ChatGPT_Analyzes_Simulating_Termination_Analyzer
For DD/HHH
int DD()
{
 int Halt_Status = HHH(DD);
 if (Halt_Status)
   HERE: goto HERE;
 return Halt_Status;
}
HHH determines whether or not DD would halt
if HHH would have been a pure simulator.
ChatGPT DOES understand hypothetical possibilities
and does understand that HHH computes the termination
status of its input on the basis of these hypothetical
possibilities.
On 5/3/2025 10:52 AM, olcott wrote:
On 5/2/2025 8:16 PM, Mike Terry wrote:
On 02/05/2025 06:06, Richard Heathfield wrote:
On 02/05/2025 05:08, dbush wrote:
On 5/1/2025 11:57 PM, olcott wrote:
On 5/1/2025 9:40 PM, dbush wrote:
<snip>
So you changed the input. Changing the input is not allowed.
I never changed the input.
Yes you did. You hypothesize changing the code of HHH, and HHH is
part of the input. So you changed the input.
Agreed.
Changing the input is not allowed.
Wweellll...
I have a very minor objection to that view, an objection that I've
wrapped up into a thought experiment.
Let us hypothesise the paradoxical existence of U, a universal
decider. If we pass it an arbitrary P and an arbitrary D, it can
defy Turing (we're just hypothesising, remember) and produce a
correct result. Cool, right? The snag is that it's a black box. We
can't see the code.
We set it to work, and for years we use it to prove all manner of
questions - PvNP, Collatz, Goldbach, Riemann, the lot - and it turns
out always to be right. That's good, right?
But then one fine day in 2038 we are finally allowed to see the
source code for U, which is when we discover that the algorithm
answers it has been providing for over a decade, thousands ofchanges the input<<< in some small way. Does that invalidate the
answers that have / all/ been verified?
Nobody would suggest that TMs aren't allowed to write to their tape!
Of course, that's part of how they work, and is not what posters mean
by PO "changing the input".
I would argue that it doesn't. Provided U(P,D) correctly reports on
the behaviour a P(D) call would produce, I would argue that that's
all that matters, and the fact that U twiddles with the P and D
tapes and turns them into P' and D' is irrelevant, as long as the
result we get is that of P(D), not P'(D').
Right. What you're describing is business as usual for TMs.
Let me show this graphically using a much simpler example - addition:
D: 1111111111+1111111
P: add 'em up
P(D)!
D': 11111111111111111
P has changed its input by changing the + to a 1 and erasing the
last 1, and D' now holds the correct answer to the question
originally posed on D.
I would argue that this is /perfectly fine/, and that there is
nothing in Turing's problem statement to forbid it. But of course we
must be careful that, even if U does change its inputs to P' and D',
it must still correctly answer the question P(D).
Nothing wrong with that.
BTW all the stuff above about universal deciders turns out to be
irrelevant to your argument! (It just seems a bit odd to choose a
non- existant TM as an example when any other (existant) TM would do
the job more clearly...)
Of course, Mr Olcott's change is rather different, because by
changing his HHH he's actually changing the behaviour of his DD -
i.e. specifying a new U - but I see no reason why he can't do that /
provided/ he can show that he always gets the correct answer. He has
so far failed to do this with the original HHH, and now he has
doubled his workload by giving himself another HHH to defend.
Right - PO's H is free to rewrite the tape in whatever way it likes,
provided in the end it gets the right answer.
The "you're not allowed to change the input" charge means something
quite different.
TLDR:Â Your talking about TMs writing to their tape as part of their
normal operation. Nothing wrong with that. PO is effectively
talking about changing the meaning of D [the input to H] half way
through the Sipser quote.
-----------------------------------------------------------------------------
NTLFM:
PO is trying to interpret Sipser's quote:
--- Start Sipser quote
     If simulating halt decider H correctly simulates its input D
     until H correctly determines that its simulated D would never >>>      stop running unless aborted then
     H can abort its simulation of D and correctly report that D
     specifies a non-halting sequence of configurations.
--- End Sipser quote
The following interpretation is ok:
    If H is given input D, and while simulating D gathers enough
    information to deduce that UTM(D) would never halt, then
    H can abort its simulation and decide D never halts.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(g) goto (d) with one more level of simulation
In other words if embedded_H was a UTM would cause
Ĥ applied to ⟨Ĥ⟩ to never halt then embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
is correctly ruled to never halt.
That is the same thing that ChatGPT agrees with and
and describes in its own words.
ChatGPT Analyzes Simulating Termination Analyzer https://www.researchgate.net/ publication/385090708_ChatGPT_Analyzes_Simulating_Termination_Analyzer
If anyone says this is incorrect ChatGPT
will argue against them every which way using
its own words. Link at end of paper.
ChatGPT actual like a profoundly brilliant genius
unless you exceed its 4000 word limit.
On 03/05/2025 19:50, Mike Terry wrote:
On 03/05/2025 06:47, Richard Heathfield wrote:
<snip>
In passing, when I nailed down "TL;DR" I felt mildly guilty for scoring so few tersinosity
points, but in return I must accuse you of undue obscurity.
TL;DR appears to have attracted a certain currency, so okay, but... NTLFM? Really? "Seek and ye
shall find", so I sought but shall findethed not. Most of my best guesses started 'Now The' and
ended rhyming with RTFM, but none of those guesses jumped out as being self-evidently right.
Would you care to translate?
I admit to making it up, but all these (usenet?) abbreviations have to start somewhere, so I
thought I would start a much needed new one!
TL;DR = too long, didn't read,
Yes, that chimes with my research, but...
introducing a short summary for someone who hasn't the inclination/time to read a long (probably
overly) verbose explanation. At least that's how I've seen it used. But then, how to introduce
the verbose explanation? I couldn't find anything for that, so I invented NTLFM; which means "Not
Too Long For Me" !
Ach! Of course.
I'm looking forward to being a footnote in history when it catches on...
In a footnote to the footnote for NTLFM I would add TOAST --- Too Obscure And Startlingly Terse.
I kind of disagree with your mild denigration of the Linz (and similar) proofs.
I wish to clarify that denigration was most certainly not my intent. There is, however, no doubt
in my mind that while Linz is undoubtedly a worthy and indeed admirable computer scientist, his
proof stands on giant shoulders. All I meant to say was that, were Linz's proof to lose its
balance and take a tumble, it would not be the fault of the shoulders.
Yeah, denigration was really the wrong word, as I know there was no bad intent anywhere. Perhaps
"downplaying" would have been what I was looking for.
<nod />
Ben pointed out there was confusion in the Linz proof with the labelling of states, and when I
looked closely at the proof I a few years ago I recall thinking Linz had munged the conversion of
(general) TM tape inputs to "H inputs" (which in Linz are binary representations of those tapes)
when duplicating D's input. Now I'm not sure about that, but can't motivate myself to get to the
bottom of it, since either way, if it is a problem it's clear how it should be fixed, and the
basis for the proof is not affected.
The proof is both "very easy" conceptually [as witnessed by how many people join in here, quickly
understanding how it works if they've not come across it before], and slightly fiddly due to the
TM H needing to have a fixed tape alphabet which must be able to represent any TM as well as any
tape input for that TM. So there are certainly opportunities to miss details especially with a
book aimed at those with a minimal maths background. Really, the only aspect of the proof
requiring careful thought is convincing yourself that the fiddliness has been handled ok, along
with understanding the notation used...
I don't see any scope for the proof actually being invalid, and PO certainly does not present any
argument for it being invalid. He simply believes his H can give the right answer for his D, and
that's the beginning and end of it all. When he developed his x96utm, it became possible to
actually run his code, and it became /manifestly/ clear his H gets the wrong answer for D. But PO
just doubles down and comes up with bizarre explanations for why he still thinks it is right when
it is obviously wrong.
As I re-read Linz /again/, two points stick out:
"We cannot find the answer by simulating the action of M on w, say by performing it on a universal
Turing machine, because there is no limit on the length of the computation. If M enters an infinite
loop, then no matter how long we wait, we can never be sure that M is in fact in a loop. It may
simply be a case of a very long computation. What we need is an algorithm that can determine the
correct answer for any M and w by performing some
analysis on the machine's description and the input. But as we
now show, no such algorithm exists."
"It is important to keep in mind what Theorem 12.1 says. It does not preclude solving the halting
problem for specific cases; often we can tell by an analysis of M and w whether or not the Turing
machine will halt. What the theorem says is that this cannot always be done; there is no algorithm
that can make a correct decision for all WM and w."
Both of these statements are self-evidently true, and both would appear to knock Mr O's HHH
completely out of the water.
I am conscious that you have already explained to me (twice!) that Mr O's approach is aimed not at
overturning the overarching indecidability proof but a mere detail of Linz's proof. Unfortunately,
your explanations have not managed to establish a firm root in what passes for my brain. This may be
because I'm too dense to grok them, or possibly it's because your explanations are TOAST (see above).
You have said, I think, that Olcott doesn't need a universal decider in order to prove his point.
But a less ambitious decider doesn't contradict Linz's proof, surely? So once more for luck, what
exactly would PO be establishing with his non-universal and impatient simulator if he could only get
it to work?
On 5/2/2025 8:16 PM, Mike Terry wrote:
On 02/05/2025 06:06, Richard Heathfield wrote:
On 02/05/2025 05:08, dbush wrote:
On 5/1/2025 11:57 PM, olcott wrote:
On 5/1/2025 9:40 PM, dbush wrote:
<snip>
So you changed the input. Changing the input is not allowed.
I never changed the input.
Yes you did. You hypothesize changing the code of HHH, and HHH is
part of the input. So you changed the input.
Agreed.
Changing the input is not allowed.
Wweellll...
I have a very minor objection to that view, an objection that I've
wrapped up into a thought experiment.
Let us hypothesise the paradoxical existence of U, a universal
decider. If we pass it an arbitrary P and an arbitrary D, it can defy
Turing (we're just hypothesising, remember) and produce a correct
result. Cool, right? The snag is that it's a black box. We can't see
the code.
We set it to work, and for years we use it to prove all manner of
questions - PvNP, Collatz, Goldbach, Riemann, the lot - and it turns
out always to be right. That's good, right?
But then one fine day in 2038 we are finally allowed to see the
source code for U, which is when we discover that the algorithm
answers it has been providing for over a decade, thousands of answerschanges the input<<< in some small way. Does that invalidate the
that have / all/ been verified?
Nobody would suggest that TMs aren't allowed to write to their tape!
Of course, that's part of how they work, and is not what posters mean
by PO "changing the input".
I would argue that it doesn't. Provided U(P,D) correctly reports on
the behaviour a P(D) call would produce, I would argue that that's
all that matters, and the fact that U twiddles with the P and D tapes
and turns them into P' and D' is irrelevant, as long as the result we
get is that of P(D), not P'(D').
Right. What you're describing is business as usual for TMs.
Let me show this graphically using a much simpler example - addition:
D: 1111111111+1111111
P: add 'em up
P(D)!
D': 11111111111111111
P has changed its input by changing the + to a 1 and erasing the last
1, and D' now holds the correct answer to the question originally
posed on D.
I would argue that this is /perfectly fine/, and that there is
nothing in Turing's problem statement to forbid it. But of course we
must be careful that, even if U does change its inputs to P' and D',
it must still correctly answer the question P(D).
Nothing wrong with that.
BTW all the stuff above about universal deciders turns out to be
irrelevant to your argument! (It just seems a bit odd to choose a
non- existant TM as an example when any other (existant) TM would do
the job more clearly...)
Of course, Mr Olcott's change is rather different, because by
changing his HHH he's actually changing the behaviour of his DD -
i.e. specifying a new U - but I see no reason why he can't do that /
provided/ he can show that he always gets the correct answer. He has
so far failed to do this with the original HHH, and now he has
doubled his workload by giving himself another HHH to defend.
Right - PO's H is free to rewrite the tape in whatever way it likes,
provided in the end it gets the right answer.
The "you're not allowed to change the input" charge means something
quite different.
TLDR:Â Your talking about TMs writing to their tape as part of their
normal operation. Nothing wrong with that. PO is effectively talking
about changing the meaning of D [the input to H] half way through the
Sipser quote.
-----------------------------------------------------------------------------
NTLFM:
PO is trying to interpret Sipser's quote:
--- Start Sipser quote
     If simulating halt decider H correctly simulates its input D
     until H correctly determines that its simulated D would never
     stop running unless aborted then
     H can abort its simulation of D and correctly report that D
     specifies a non-halting sequence of configurations.
--- End Sipser quote
The following interpretation is ok:
    If H is given input D, and while simulating D gathers enough
    information to deduce that UTM(D) would never halt, then
    H can abort its simulation and decide D never halts.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(g) goto (d) with one more level of simulation
In other words if embedded_H was a UTM
would cause> Ĥ applied to ⟨Ĥ⟩ to never halt then embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
is correctly ruled to never halt.
On 5/2/2025 8:16 PM, Mike Terry wrote:
On 02/05/2025 06:06, Richard Heathfield wrote:
On 02/05/2025 05:08, dbush wrote:
On 5/1/2025 11:57 PM, olcott wrote:
On 5/1/2025 9:40 PM, dbush wrote:
<snip>
So you changed the input. Changing the input is not allowed.
I never changed the input.
Yes you did. You hypothesize changing the code of HHH, and HHH is
part of the input. So you changed the input.
Agreed.
Changing the input is not allowed.
Wweellll...
I have a very minor objection to that view, an objection that I've
wrapped up into a thought experiment.
Let us hypothesise the paradoxical existence of U, a universal
decider. If we pass it an arbitrary P and an arbitrary D, it can defy
Turing (we're just hypothesising, remember) and produce a correct
result. Cool, right? The snag is that it's a black box. We can't see
the code.
We set it to work, and for years we use it to prove all manner of
questions - PvNP, Collatz, Goldbach, Riemann, the lot - and it turns
out always to be right. That's good, right?
But then one fine day in 2038 we are finally allowed to see the
source code for U, which is when we discover that the algorithm
answers it has been providing for over a decade, thousands of answerschanges the input<<< in some small way. Does that invalidate the
that have / all/ been verified?
Nobody would suggest that TMs aren't allowed to write to their tape!
Of course, that's part of how they work, and is not what posters mean
by PO "changing the input".
I would argue that it doesn't. Provided U(P,D) correctly reports on
the behaviour a P(D) call would produce, I would argue that that's
all that matters, and the fact that U twiddles with the P and D tapes
and turns them into P' and D' is irrelevant, as long as the result we
get is that of P(D), not P'(D').
Right. What you're describing is business as usual for TMs.
Let me show this graphically using a much simpler example - addition:
D: 1111111111+1111111
P: add 'em up
P(D)!
D': 11111111111111111
P has changed its input by changing the + to a 1 and erasing the last
1, and D' now holds the correct answer to the question originally
posed on D.
I would argue that this is /perfectly fine/, and that there is
nothing in Turing's problem statement to forbid it. But of course we
must be careful that, even if U does change its inputs to P' and D',
it must still correctly answer the question P(D).
Nothing wrong with that.
BTW all the stuff above about universal deciders turns out to be
irrelevant to your argument! (It just seems a bit odd to choose a
non- existant TM as an example when any other (existant) TM would do
the job more clearly...)
Of course, Mr Olcott's change is rather different, because by
changing his HHH he's actually changing the behaviour of his DD -
i.e. specifying a new U - but I see no reason why he can't do that /
provided/ he can show that he always gets the correct answer. He has
so far failed to do this with the original HHH, and now he has
doubled his workload by giving himself another HHH to defend.
Right - PO's H is free to rewrite the tape in whatever way it likes,
provided in the end it gets the right answer.
The "you're not allowed to change the input" charge means something
quite different.
TLDR:Â Your talking about TMs writing to their tape as part of their
normal operation. Nothing wrong with that. PO is effectively talking
about changing the meaning of D [the input to H] half way through the
Sipser quote.
-----------------------------------------------------------------------------
NTLFM:
PO is trying to interpret Sipser's quote:
--- Start Sipser quote
     If simulating halt decider H correctly simulates its input D
     until H correctly determines that its simulated D would never
     stop running unless aborted then
     H can abort its simulation of D and correctly report that D
     specifies a non-halting sequence of configurations.
--- End Sipser quote
The following interpretation is ok:
    If H is given input D, and while simulating D gathers enough
    information to deduce that UTM(D) would never halt, then
    H can abort its simulation and decide D never halts.
That is the same way that ChatGPT understands it.
*ChatGPT Analyzes Simulating Termination Analyzer* https://www.researchgate.net/ publication/385090708_ChatGPT_Analyzes_Simulating_Termination_Analyzer
For DD/HHH
int DD()
{
 int Halt_Status = HHH(DD);
 if (Halt_Status)
   HERE: goto HERE;
 return Halt_Status;
}
HHH determines whether or not DD would halt
if HHH would have been a pure simulator.
On 03/05/2025 20:45, Richard Heathfield wrote:
I am conscious that you have already explained to me (twice!)
that Mr O's approach is aimed not at overturning the
overarching indecidability proof but a mere detail of Linz's
proof. Unfortunately, your explanations have not managed to
establish a firm root in what passes for my brain.
This may be
because I'm too dense to grok them, or possibly it's because
your explanations are TOAST (see above).
I generally think I post way too much,
and tend to wander off
topic with unnecessary background and so on,
and probably I write
too much from a "maths" perspective, because that's my
background. Not sure if I can change any of that! :) Just ask
if I use obscure notation or let me know if I'm going too
fast/slow. Part of the problem is I don't know your background
and what things you're super familiar with.
You have said, I think, that Olcott doesn't need a universal
decider in order to prove his point. But a less ambitious
decider doesn't contradict Linz's proof, surely? So once more
for luck, what exactly would PO be establishing with his
non-universal and impatient simulator if he could only get it
to work?
Yes. PO is aiming to refute the /proof method/ that Linz (and
similar) proofs use, i.e. to attack the /reasoning/ behind the
proof. In effect, he is saying that his HHH/DD provide a
counter-example to that reasoning. His HHH/DD are not full halt
deciders - they're /partial/ halt deciders but that would be
enough. I cover what a partial HD is below, and why it is enough
for his argument [..if HHH/DD worked as originally claimed..]
If he was successful with his HHH/DD programs, it would mean the
Linz proof contained some logical error, and so the conclusion of
the proof (the HP theorem) would not be warranted /by that
proof/, We would have to cross that proof out of our Master Book
Of Mathematical Theorems And Their Proofs! As there are other
proofs of the theorem, the theorem itself could remain.
It would be like the following scenario:Â there are many
alternative proofs of Pythagorus' Theorem, but let's imagine that
one of them - the "MikeT" proof - is the first one taught to all
school children across the world, and it's been that way for the
last 50 years. Suddenly PO finds a flaw in that proof! Sure,
there are other proofs without that flaw so we still trust
Pythagorus' Theorem, but we're not going to continue teaching
children an incorrect proof of it, right. So finding such a flaw
would force many changes on our education system and be highly
interesting in its own right.
This doesn't explain exactly how PO's HHH/DD would "refute" the
Linz proof, so that's what the rest of the post tries to do.
BTW, when I refer to "the Linz proof" it is purely because the
Linz book is apparently the one that PO has access to, and when
he started posting here he claimed to have refuted the "Linz"
proof that appears in that book. As you suspect, the proof is
nothing to do with Linz other than appearing in his book!
 It
also appears I expect in some form in most computer science books
covering computation theory, because it's so well known. Hmm,
not sure who discovered it, but it would be one of the big guys
like Turing, Church, Kleene,... all doing related work in the
early days of the field.
So to say what PO's code would refute, I need to explain exactly
how the Linz proof works. Sorry if you already perfectly clear
on that!
This next bit might be a missing key for you...   Looking at the
above, we started by me giving you a "halt decider" H. What if I
only gave you a lesser achievement: a "partial halt decider" that
correctly decides halting for certain (P,I) inputs, but fails to
halt for all the rest?
 The answer is the same logic still
applies, but the conclusion is slightly different:
-Â I give you a /partial/ HDÂ H
-Â You follow the same instructions to create the new TM, H^
-Â The same reasoning of the Linz proof shows that my H does not
correctly decide halting
  for the case of TM H^ running against input <H^>
  a) If H decides HALTS, we can show H^(<H^>) never halts
  b) If H decides NEVER_HALTS, we can show H^(<H^>) halts
  c) If H fails to decide (i.e. it loops) then H^(<H^>) never
halts
      This last possibility is new, because H is only a partial
halt decider
Now we can look at what PO claims to have: a *partial* halt
decider H, which CORRECTLY decides its corresponding input
(<H^>,<H^>). Specifically, he claims his H decides NEVER_HALTS,
and that indeed H^(<H^>) never halts. This contradicts the Linz
proof /reasoning/ which lead to (b) above.
Since the Linz proof reasoning would have been shown to reach a
false conclusion [in the case of PO's HHH/DD programs], the
reasoning must be wrong somewhere, and if the reasoning is wrong
it can't be used in the Linz proof. It is ok here that H is only
a partial halt decider - in fact the above only requires that
PO's H correctly decides the one H^(<H^>) case to get the
contradiction.
Er, that's it!
Just as a reminder I'll repeat the final outcome of all this:
-Â PO's H does decide NEVER_HALTS for TM H^ running with input <H^>.
-Â PO's H^ running with input <H^> in fact halts, in line with
Linz logic (b) above.
A final observation - nothing in this post is anything to do with "simulation". That comes later looking at how PO's H supposedly
works...
They simply guess that because DD(DD) halts that
DD correctly simulated by HHH must also halt.
They cannot provide these detailed steps of the
execution trace of each machine instruction
BECAUSE THEY KNOW THAT THEY ARE WRONG AND ONLY PLAYING HEAD GAMES.
On 5/4/2025 11:21 AM, Richard Heathfield wrote:
On 04/05/2025 17:06, olcott wrote:
<snip>
They simply guess that because DD(DD) halts that
DD correctly simulated by HHH must also halt.
It's not a guess. If direct execution halts, so must the
simulation.
Maybe you are confused between halting (reaching
a final halt state and terminating normally)
with stopping running for any reason such as
an aborted emulation. *THEY ARE NOT THE SAME*
On 04/05/2025 01:20, Mike Terry wrote:
On 03/05/2025 20:45, Richard Heathfield wrote:
<snip>
I am conscious that you have already explained to me (twice!) that Mr O's approach is aimed not
at overturning the overarching indecidability proof but a mere detail of Linz's proof.
Unfortunately, your explanations have not managed to establish a firm root in what passes for my
brain.
Third time's a charm, I think, or at least I'm further forward. (See question about a mile
VVVVVsouthVVVVV of here.)
In case I ever bail again, you have my full permission to remind me of <~/alldata/usenet/M_Terry_explains_olcott_reasoning.eml> where I have saved your reply for future
re-enlightenment.
This may be because I'm too dense to grok them, or possibly it's because your explanations are
TOAST (see above).
Turned out to be 50/50.
I generally think I post way too much,
I think Usenauts are best measured by their S/N ratio. That is, it's what you post rather than how
much there is of it.
and tend to wander off topic with unnecessary background and so on,
Isaac Asimov was always at his happiest when starting an essay with the magic words "The Ancient
Greeks..." In 1965 he wrote a book to be called "The Neutrino". He spent the first three quarters or
so of the book on what he considered to be /necessary/ background, and Chapter 500-or-so is called
"Enter The Neutrino". When he got the proofs back for checking, he saw that his copy editor had
pencilled into the margin "AT LAST!"
and probably I write too much from a "maths" perspective, because that's my background. Not sure
if I can change any of that! :) Just ask if I use obscure notation or let me know if I'm going
too fast/slow. Part of the problem is I don't know your background and what things you're super
familiar with.
ISTR that I have recently gone on record as claiming (when asked if I have ever done any
programming) to be a professional potato painter. The claim is rather less accurate than I generally
try to be, and whilst it is true that I am super familiar (and perhaps too familiar) with potatoes,
I haven't actually painted one since infants' school.
My background? Unfortunately my potato-painting career never really took off, so I decided instead
to earn my corn writing computer programs for a living.
Any good?
BTW, when I refer to "the Linz proof" it is purely because the Linz book is apparently the one
that PO has access to, and when he started posting here he claimed to have refuted the "Linz"
proof that appears in that book. As you suspect, the proof is nothing to do with Linz other than
appearing in his book!
I am reminded of Hellin's Law, which documents the as yet unexplained fact that for n>1, n-tuple
births occur once in 89^{n-1} pregnancies. In 1895, Hellin wrote down what biologists and
demographers had already known for years. This penmanship appears to be his only contribution to the
matter, and yet... Hellin's Law.
It also appears I expect in some form in most computer science books covering computation
theory, because it's so well known. Hmm, not sure who discovered it, but it would be one of the
big guys like Turing, Church, Kleene,... all doing related work in the early days of the field.
Turing, I think., in 1936.
ON COMPUTABLE NUMBERS, WITH AN APPLICATION TO
THE ENTSCHEIDUNGSPROBLEM
I have a 2MB PDF copy. I can't remember where I found it but, if you want it, drop me an email and
I'll send it by return.
So to say what PO's code would refute, I need to explain exactly how the Linz proof works. Sorry
if you already perfectly clear on that!
I'm fine with the general idea of the proof. If we have a universal decider U we can (easily!) use
it to make a program that it can't decide, and we have reductio QED.
<snipped but not skipped>
This next bit might be a missing key for you... Looking at the above, we started by me giving
you a "halt decider" H. What if I only gave you a lesser achievement: a "partial halt decider"
that correctly decides halting for certain (P,I) inputs, but fails to halt for all the rest?
What's to stop the partial decider from deciding pseudorandomly? For example: hashing the input
tapes and deciding according to the hash modulo 2? This would:
1) always decide (as required);
2) sometimes get it right (as required);
3) sometimes get it wrong (as required if it's to be only 'partial');
4) always make the same decision when given the same input (clearly desirable);
5) be trivial to write;
6) would step around all the simulation nonsense and puncture about 99% of the current quarrel.
7) It could obviously be arranged if need be to interpret the hash mod 2 so that when fed itself as
input it gets itself (a) right or (b) wrong.
Clearly this won't do, because surely /somebody/ would have pointed it out by now, but... /why/
won't it do?
int sum(int x, int y) { return x + y; }
The mapping from sum(3,2) to sum 5 + 6 does not
exist
for the same reason that the mapping from DD correctly
simulated by HHH to DD(DD) does not exist.
THE MAPPING MUST BE WHAT THE INPUT ACTUALLY SPECIES
NOT MERELY WHAT SOMEONE EXPECTS.
I hereby overload the
term "mapping" with this new meaning.
Computable functions REPORT ON WHAT THEIR INPUT ACTUALLY SPECIFIES
It was more how much maths background you have
+ familiarity with HP proof you have.
What's to stop the partial decider from deciding
pseudorandomly? For example: hashing the input tapes and
deciding according to the hash modulo 2? This would:
1) always decide (as required);
2) sometimes get it right (as required);
3) sometimes get it wrong (as required if it's to be only
'partial');
No, partial halt deciders [*PHD*s] aren't supposed to get it
wrong!
If they don't know the answer they're supposed to never
answer, but if they do answer [i.e. HALTS or NEVER_HALTS] it must
be right. We could define PHDs so that they have a 3rd answer
DONT_KNOW, but assuming we still allow them to never answer I
don't see that the DONT_KNOW answer adds much. [the new PHDs
would be equivalent to my definition]
If we add a DONT_KNOW answer, and then insist the PHD must halt
with one of the 3 answers, I think that would be a different
concept, because a PHD might be searching for a particular test
condition and never find it. That would be an infinite loop,
which I consider reasonable, but if it is forced instead to
decide DONT_KNOW in finite time, then such a potentially unending
search would be excluded. So I think we have a different concept
of PHD now.
Actually, while I've talked about PHDs which are not allowed to
decide incorrectly, in fact for PO's purposes it wouldn't matter
if we allowed PHDs to decide inputs incorrectly like you're
imagining. We could be talking about a new type of TM, maybe call
it a "Putative PHD"Â [*PPHD*] which takes the (P,I) input, and
may decide HALTS/NEVER_HALTS or never decide, and PPHDs have no
requirement to answer correctly. [PO's HHH is really a PPHD, not
a PHD as it sometimes answers incorrectly]
Everything I've said about PHD's in relation to PO's claims to
refute Linz, would work equally well with PPHDs! That's because
all that really matters for PO is that the ONE SPECIFIC INPUT
(<H^>,<H^>) must be decided correctly. It's still the case, even
for PPHDs, that the reasoning used in the Linz proof implies that
if H is a PPHD, H will NOT decide input (<H^>,<H^>) correctly.
So if PO could provides even a PPHD H that decides (<H^>,<H^>)
/correctly/ that shows a problem with the Linz proof logic. [Of
course, PO cannot provide such an H.]
Clearly this won't do, because surely /somebody/ would have
pointed it out by now, but... /why/ won't it do?
That's a good question!
Given that PO's /only aim/ is to deliver an H which works for ONE
SPECIFIC INPUT (<H^>,<H^>), why can't he just assume in his code
for H that that is the input, and simply give whatever answer he
needs for his argument to work? Someone else pointed this out a
few years ago - PO could just write a trivial stub that works in
this one input scenario.
 [Hmm, I think that was Malcolm McLean
who hasn't posted for a couple of years.]
Logically that makes perfect sense. But for PO I suppose the
answer is that if he just did that, it would be too obvious that
it Just Doesn't Work. In fact it would be obvious that it
/can't/ work due to the way H^ relates to H, together with the
reasoning in the Linz proof.
In the end the answer to your question is that PO /needs/ all the
faffing with simulation to maintain his faulty intuitions /in his
own mind/.
On 5/4/2025 11:21 AM, Richard Heathfield wrote:
On 04/05/2025 17:06, olcott wrote:
<snip>
They simply guess that because DD(DD) halts that
DD correctly simulated by HHH must also halt.
It's not a guess. If direct execution halts, so must the simulation.
_DD()
[00002133] 55        push ebp     ; housekeeping
[00002134] 8bec      mov ebp,esp  ; housekeeping
[00002136] 51        push ecx     ; make space for local [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404Â Â Â Â add esp,+04
[00002144] 8945fc    mov [ebp-04],eax
[00002147] 837dfc00Â Â cmp dword [ebp-04],+00
[0000214b] 7402Â Â Â Â Â Â jz 0000214f
[0000214d] ebfe      jmp 0000214d
[0000214f] 8b45fc    mov eax,[ebp-04]
[00002152] 8be5Â Â Â Â Â Â mov esp,ebp
[00002154] 5d        pop ebp
[00002155] c3Â Â Â Â Â Â Â Â ret
Size in bytes:(0035) [00002155]
Maybe you are confused between halting (reaching
a final halt state and terminating normally)
with stopping running for any reason such as
an aborted emulation. *THEY ARE NOT THE SAME*
DD correctly emulated by HHH stops running when
HHH aborts its simulation.
DD correctly emulated by HHH cannot possibly
reach its "return" instruction final halt state.
You must be imagining that DD emulated by HHH
leaps over the "call" instruction and jumps
straight to the "ret" instruction.
On 5/4/2025 2:01 PM, Richard Heathfield wrote:
On 04/05/2025 18:30, olcott wrote:
On 5/4/2025 11:21 AM, Richard Heathfield wrote:<snip>
On 04/05/2025 17:06, olcott wrote:
<snip>
They simply guess that because DD(DD) halts that
DD correctly simulated by HHH must also halt.
It's not a guess. If direct execution halts, so must the simulation.
Maybe you are confused between halting (reaching
a final halt state and terminating normally)
with stopping running for any reason such as
an aborted emulation. *THEY ARE NOT THE SAME*
Maybe you are confused between equality and inequality.
If DD halts when directly executed, then a correct simulation of DD
must also halt.
ONLY IF YOU STUPIDLY IGNORE THE X86 LANGUAGE
THAT PROVES THAT DD CORRECTLY EMULATED BY HHH IS
NOT THE SAME EXECUTION TRACE AS DIRECTLY EXECUTED DD(DD)
_DD()
[00002133] 55        push ebp     ; housekeeping
[00002134] 8bec      mov ebp,esp  ; housekeeping
[00002136] 51        push ecx     ; make space for local [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404Â Â Â Â add esp,+04
[00002144] 8945fc    mov [ebp-04],eax
[00002147] 837dfc00Â Â cmp dword [ebp-04],+00
[0000214b] 7402Â Â Â Â Â Â jz 0000214f
[0000214d] ebfe      jmp 0000214d
[0000214f] 8b45fc    mov eax,[ebp-04]
[00002152] 8be5Â Â Â Â Â Â mov esp,ebp
[00002154] 5d        pop ebp
[00002155] c3Â Â Â Â Â Â Â Â ret
Size in bytes:(0035) [00002155]
After DD is correctly emulated by HHH
HHH MUST EMULATE ITSELF EMULATING DD
OR IT VIOLATES THE RULES OF THE X86 LANGUAGE.
The relationshop between HHH and DD is the exact
same infinite recursion as the above HHH and DDD
except that HHH is smart enough to cut it off
and not get stuck in infinite recursion.
On 5/3/2025 4:28 PM, dbush wrote:
On 5/3/2025 3:45 PM, Richard Heathfield wrote:
I am conscious that you have already explained to me (twice!) that Mr
O's approach is aimed not at overturning the overarching
indecidability proof but a mere detail of Linz's proof.
Unfortunately, your explanations have not managed to establish a firm
root in what passes for my brain. This may be because I'm too dense
to grok them, or possibly it's because your explanations are TOAST
(see above).
You have said, I think, that Olcott doesn't need a universal decider
in order to prove his point. But a less ambitious decider doesn't
contradict Linz's proof, surely? So once more for luck, what exactly
would PO be establishing with his non-universal and impatient
simulator if he could only get it to work?
The core issue is that PO, despise being nearly 70 and having worked
as a programmer, fundamentally doesn't understand proof by contradiction.
The actual issue is the NO ONE here (or perhaps anywhere)
sufficiently understands the key details about
COMPUTING THE MAPPING FROM AN INPUT TO AN OUTPUT.
Many here know that a mapping from the input must be
computed. What they don't know are ALL of the tiny
detailed steps required to compute this mapping.
They simply guess that because DD(DD) halts that
DD correctly simulated by HHH must also halt.
They cannot provide these detailed steps of the
execution trace of each machine instruction showing
exactly how DD correctly emulated by HHH halts
BECAUSE THEY KNOW THAT THEY ARE WRONG AND ONLY PLAYING HEAD GAMES.
_DD()
[00002133] 55        push ebp     ; housekeeping
[00002134] 8bec      mov ebp,esp  ; housekeeping
[00002136] 51        push ecx     ; make space for local [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404Â Â Â Â add esp,+04
[00002144] 8945fc    mov [ebp-04],eax
[00002147] 837dfc00Â Â cmp dword [ebp-04],+00
[0000214b] 7402Â Â Â Â Â Â jz 0000214f
[0000214d] ebfe      jmp 0000214d
[0000214f] 8b45fc    mov eax,[ebp-04]
[00002152] 8be5Â Â Â Â Â Â mov esp,ebp
[00002154] 5d        pop ebp
[00002155] c3Â Â Â Â Â Â Â Â ret
Size in bytes:(0035) [00002155]
On 5/4/2025 11:57 AM, dbush wrote:
On 5/4/2025 12:06 PM, olcott wrote:
On 5/3/2025 4:28 PM, dbush wrote:
On 5/3/2025 3:45 PM, Richard Heathfield wrote:
I am conscious that you have already explained to me (twice!) that
Mr O's approach is aimed not at overturning the overarching
indecidability proof but a mere detail of Linz's proof.
Unfortunately, your explanations have not managed to establish a
firm root in what passes for my brain. This may be because I'm too
dense to grok them, or possibly it's because your explanations are
TOAST (see above).
You have said, I think, that Olcott doesn't need a universal
decider in order to prove his point. But a less ambitious decider
doesn't contradict Linz's proof, surely? So once more for luck,
what exactly would PO be establishing with his non-universal and
impatient simulator if he could only get it to work?
The core issue is that PO, despise being nearly 70 and having worked
as a programmer, fundamentally doesn't understand proof by
contradiction.
The actual issue is the NO ONE here (or perhaps anywhere)
sufficiently understands the key details about
COMPUTING THE MAPPING FROM AN INPUT TO AN OUTPUT.
Many here know that a mapping from the input must be
computed.
False. There is no requirement that a mapping is computable. The
halting function is one such mapping, as Linz and others have proved
and you have *explictly* agreed is correct.
What they don't know are ALL of the tiny
detailed steps required to compute this mapping.
And if the mapping isn't computable, like the halting function, there
are no such steps.
int sum(int x, int y) { return x + y; }
The mapping from sum(3,2) to sum 5 + 6 does not
exist
for the same reason that the mapping from DD correctly
simulated by HHH to DD(DD) does not exist.
THE MAPPING MUST BE WHAT THE INPUT ACTUALLY SPECIES
NOT MERELY WHAT SOMEONE EXPECTS.
They simply guess that because DD(DD) halts that
DD correctly simulated by HHH must also halt.
A correct simulation is stipulated to be one that exactly matches the
behavior of the machine to be simulated.
DD is not correctly simulated by HHH, as the last instruction
simulated is not simulated correctly, because the x86 language
requires any executed instruction other than a HLT to be followed by
the execution of the next instruction.
We also know that "DD correctly simulated by HHH" is PO-speak for
"Replacing the code of HHH with an unconditional simulator and
subsequently running HHH(DD)", as you have agreed and given permission
to replace the former with the later.
This means that you're changing the input.
Changing the input is not allowed.
They cannot provide these detailed steps of the
execution trace of each machine instruction showing
exactly how DD correctly emulated by HHH halts
BECAUSE THEY KNOW THAT THEY ARE WRONG AND ONLY PLAYING HEAD GAMES.
That you don't understand requirements doesn't make it a head game.
On 5/4/2025 12:48 PM, dbush wrote:
On 5/4/2025 1:38 PM, olcott wrote:
On 5/4/2025 11:57 AM, dbush wrote:
On 5/4/2025 12:06 PM, olcott wrote:
On 5/3/2025 4:28 PM, dbush wrote:
On 5/3/2025 3:45 PM, Richard Heathfield wrote:
I am conscious that you have already explained to me (twice!)
that Mr O's approach is aimed not at overturning the overarching >>>>>>> indecidability proof but a mere detail of Linz's proof.
Unfortunately, your explanations have not managed to establish a >>>>>>> firm root in what passes for my brain. This may be because I'm
too dense to grok them, or possibly it's because your
explanations are TOAST (see above).
You have said, I think, that Olcott doesn't need a universal
decider in order to prove his point. But a less ambitious decider >>>>>>> doesn't contradict Linz's proof, surely? So once more for luck,
what exactly would PO be establishing with his non-universal and >>>>>>> impatient simulator if he could only get it to work?
The core issue is that PO, despise being nearly 70 and having
worked as a programmer, fundamentally doesn't understand proof by
contradiction.
The actual issue is the NO ONE here (or perhaps anywhere)
sufficiently understands the key details about
COMPUTING THE MAPPING FROM AN INPUT TO AN OUTPUT.
Many here know that a mapping from the input must be
computed.
False. There is no requirement that a mapping is computable. The
halting function is one such mapping, as Linz and others have proved
and you have *explictly* agreed is correct.
What they don't know are ALL of the tiny
detailed steps required to compute this mapping.
And if the mapping isn't computable, like the halting function,
there are no such steps.
int sum(int x, int y) { return x + y; }
The mapping from sum(3,2) to sum 5 + 6 does not
exist
Category error. A mapping is an association between an input domain
and an output domain, not a C function call to a value.
We can be more vague and say there is a mapping
from pairs of integers to their integer sum value.
The mapping from sum(3,2) is much more specific it
only maps to 5 by the rules of arithmetic.
If there is no preexisting term for the mapping from
one specific input to one specific output via a specific
set of transformation rules then I hereby overload the
term "mapping" with this new meaning.
INPUTS to functions computed by Turing Machines
must correspond to OUTPUTS via an algorithm.
The WILD GUESS that DD correctly emulated by HHH
must halt because DD(DD) halts ignores that a
specific algorithms is required.
If you cannot show every detailed step of the full
execution trace of HOW DD emulated by HHH
reaches its own emulated final halt state
THEN ALL YOU HAVE IS BLUSTER.
_DD()
[00002133] 55        push ebp     ; housekeeping
[00002134] 8bec      mov ebp,esp  ; housekeeping
[00002136] 51        push ecx     ; make space for local [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404Â Â Â Â add esp,+04
[00002144] 8945fc    mov [ebp-04],eax
[00002147] 837dfc00Â Â cmp dword [ebp-04],+00
[0000214b] 7402Â Â Â Â Â Â jz 0000214f
[0000214d] ebfe      jmp 0000214d
[0000214f] 8b45fc    mov eax,[ebp-04]
[00002152] 8be5Â Â Â Â Â Â mov esp,ebp
[00002154] 5d        pop ebp
[00002155] c3Â Â Â Â Â Â Â Â ret
Size in bytes:(0035) [00002155]
On 5/4/2025 2:13 PM, Richard Heathfield wrote:
On 04/05/2025 18:38, olcott wrote:
<snip>
int sum(int x, int y) { return x + y; }
The mapping from sum(3,2) to sum 5 + 6 does not
exist
That's meaningless. Addition maps two ordinary numbers onto one
number. The mapping of 3 + 2 is to 5, and the mapping of 5 + 6 is to
11. sum(3,2) is the notation of a programming language's function
call, not a mapping. Are you confusing 'computable function' with
'programming language procedure'?
for the same reason that the mapping from DD correctly
simulated by HHH to DD(DD) does not exist.
So you're saying that HHH cannot correctly simulate DD? I agree.
Yes and int sum(int x, int y) { return x + y; }
can not have sum(3,2) return the sum of 5 + 7 for the same reason.
Computable functions REPORT ON WHAT THEIR INPUT ACTUALLY SPECIFIES
not some twisted delusion.
On 5/3/2025 4:47 PM, Richard Damon wrote:
On 5/3/25 1:07 PM, olcott wrote:
On 5/2/2025 8:16 PM, Mike Terry wrote:
On 02/05/2025 06:06, Richard Heathfield wrote:
On 02/05/2025 05:08, dbush wrote:
On 5/1/2025 11:57 PM, olcott wrote:
On 5/1/2025 9:40 PM, dbush wrote:
<snip>
So you changed the input. Changing the input is not allowed. >>>>>>>>
I never changed the input.
Yes you did. You hypothesize changing the code of HHH, and HHH is >>>>>> part of the input. So you changed the input.
Agreed.
Changing the input is not allowed.
Wweellll...
I have a very minor objection to that view, an objection that I've
wrapped up into a thought experiment.
Let us hypothesise the paradoxical existence of U, a universal
decider. If we pass it an arbitrary P and an arbitrary D, it can
defy Turing (we're just hypothesising, remember) and produce a
correct result. Cool, right? The snag is that it's a black box. We
can't see the code.
We set it to work, and for years we use it to prove all manner of
questions - PvNP, Collatz, Goldbach, Riemann, the lot - and it
turns out always to be right. That's good, right?
But then one fine day in 2038 we are finally allowed to see the
source code for U, which is when we discover that the algorithm
answers it has been providing for over a decade, thousands ofchanges the input<<< in some small way. Does that invalidate the
answers that have / all/ been verified?
Nobody would suggest that TMs aren't allowed to write to their tape!
Of course, that's part of how they work, and is not what posters
mean by PO "changing the input".
I would argue that it doesn't. Provided U(P,D) correctly reports on
the behaviour a P(D) call would produce, I would argue that that's
all that matters, and the fact that U twiddles with the P and D
tapes and turns them into P' and D' is irrelevant, as long as the
result we get is that of P(D), not P'(D').
Right. What you're describing is business as usual for TMs.
Let me show this graphically using a much simpler example - addition: >>>>>
D: 1111111111+1111111
P: add 'em up
P(D)!
D': 11111111111111111
P has changed its input by changing the + to a 1 and erasing the
last 1, and D' now holds the correct answer to the question
originally posed on D.
I would argue that this is /perfectly fine/, and that there is
nothing in Turing's problem statement to forbid it. But of course
we must be careful that, even if U does change its inputs to P' and
D', it must still correctly answer the question P(D).
Nothing wrong with that.
BTW all the stuff above about universal deciders turns out to be
irrelevant to your argument! (It just seems a bit odd to choose a
non- existant TM as an example when any other (existant) TM would do
the job more clearly...)
Of course, Mr Olcott's change is rather different, because by
changing his HHH he's actually changing the behaviour of his DD -
i.e. specifying a new U - but I see no reason why he can't do
that / provided/ he can show that he always gets the correct
answer. He has so far failed to do this with the original HHH, and
now he has doubled his workload by giving himself another HHH to
defend.
Right - PO's H is free to rewrite the tape in whatever way it likes,
provided in the end it gets the right answer.
The "you're not allowed to change the input" charge means something
quite different.
TLDR:Â Your talking about TMs writing to their tape as part of their
normal operation. Nothing wrong with that. PO is effectively
talking about changing the meaning of D [the input to H] half way
through the Sipser quote.
-----------------------------------------------------------------------------
NTLFM:
PO is trying to interpret Sipser's quote:
--- Start Sipser quote
     If simulating halt decider H correctly simulates its input D >>>>      until H correctly determines that its simulated D would never >>>>      stop running unless aborted then
     H can abort its simulation of D and correctly report that D >>>>      specifies a non-halting sequence of configurations.
--- End Sipser quote
The following interpretation is ok:
    If H is given input D, and while simulating D gathers enough
    information to deduce that UTM(D) would never halt, then
    H can abort its simulation and decide D never halts.
That is the same way that ChatGPT understands it.
*ChatGPT Analyzes Simulating Termination Analyzer*
https://www.researchgate.net/
publication/385090708_ChatGPT_Analyzes_Simulating_Termination_Analyzer
For DD/HHH
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
HHH determines whether or not DD would halt
if HHH would have been a pure simulator.
But HHH is NOT a pure simulator, so that doesn't matter, at that HHH
never answers
Remember the input DD depend on the code of the decider it is defined
to call, so your input changes.
It seems, you are just so stupid as to not understand what a program
actually is.
ChatGPT DOES understand hypothetical possibilities
and does understand that HHH computes the termination
status of its input on the basis of these hypothetical
possibilities.
No, it just shows that it is as stupid as you, and believes (or
pretends to in order to make you happy) your lies.
If that was true then you would be able to point
out its mistake. The only reason that you cannot
do this is THAT IT MADE NO MISTAKE!
On 5/3/2025 7:20 PM, Mike Terry wrote:
On 03/05/2025 20:45, Richard Heathfield wrote:
On 03/05/2025 19:50, Mike Terry wrote:
On 03/05/2025 06:47, Richard Heathfield wrote:
<snip>
In passing, when I nailed down "TL;DR" I felt mildly guilty for
scoring so few tersinosity points, but in return I must accuse you
of undue obscurity.
TL;DR appears to have attracted a certain currency, so okay, but...
NTLFM? Really? "Seek and ye shall find", so I sought but shall
findethed not. Most of my best guesses started 'Now The' and ended
rhyming with RTFM, but none of those guesses jumped out as being
self-evidently right. Would you care to translate?
I admit to making it up, but all these (usenet?) abbreviations have
to start somewhere, so I thought I would start a much needed new one!
TL;DR = too long, didn't read,
Yes, that chimes with my research, but...
introducing a short summary for someone who hasn't the inclination/
time to read a long (probably overly) verbose explanation. At least
that's how I've seen it used. But then, how to introduce the
verbose explanation? I couldn't find anything for that, so I
invented NTLFM; which means "Not Too Long For Me" !
Ach! Of course.
I'm looking forward to being a footnote in history when it catches
on...
In a footnote to the footnote for NTLFM I would add TOAST --- Too
Obscure And Startlingly Terse.
I kind of disagree with your mild denigration of the Linz (and
similar) proofs.
I wish to clarify that denigration was most certainly not my
intent. There is, however, no doubt in my mind that while Linz is
undoubtedly a worthy and indeed admirable computer scientist, his
proof stands on giant shoulders. All I meant to say was that, were
Linz's proof to lose its balance and take a tumble, it would not be
the fault of the shoulders.
Yeah, denigration was really the wrong word, as I know there was no
bad intent anywhere. Perhaps "downplaying" would have been what I
was looking for.
<nod />
Ben pointed out there was confusion in the Linz proof with the
labelling of states, and when I looked closely at the proof I a few
years ago I recall thinking Linz had munged the conversion of
(general) TM tape inputs to "H inputs" (which in Linz are binary
representations of those tapes) when duplicating D's input. Now I'm
not sure about that, but can't motivate myself to get to the bottom
of it, since either way, if it is a problem it's clear how it should
be fixed, and the basis for the proof is not affected.
The proof is both "very easy" conceptually [as witnessed by how many
people join in here, quickly understanding how it works if they've
not come across it before], and slightly fiddly due to the TM H
needing to have a fixed tape alphabet which must be able to
represent any TM as well as any tape input for that TM. So there
are certainly opportunities to miss details especially with a book
aimed at those with a minimal maths background. Really, the only
aspect of the proof requiring careful thought is convincing yourself
that the fiddliness has been handled ok, along with understanding
the notation used...
I don't see any scope for the proof actually being invalid, and PO
certainly does not present any argument for it being invalid. He
simply believes his H can give the right answer for his D, and
that's the beginning and end of it all. When he developed his
x96utm, it became possible to actually run his code, and it became /
manifestly/ clear his H gets the wrong answer for D. But PO just
doubles down and comes up with bizarre explanations for why he still
thinks it is right when it is obviously wrong.
As I re-read Linz /again/, two points stick out:
"We cannot find the answer by simulating the action of M on w, say by
performing it on a universal Turing machine, because there is no
limit on the length of the computation. If M enters an infinite loop,
then no matter how long we wait, we can never be sure that M is in
fact in a loop. It may simply be a case of a very long computation.
What we need is an algorithm that can determine the correct answer
for any M and w by performing some
analysis on the machine's description and the input. But as we
now show, no such algorithm exists."
"It is important to keep in mind what Theorem 12.1 says. It does not
preclude solving the halting problem for specific cases; often we can
tell by an analysis of M and w whether or not the Turing machine will
halt. What the theorem says is that this cannot always be done; there
is no algorithm that can make a correct decision for all WM and w."
Both of these statements are self-evidently true, and both would
appear to knock Mr O's HHH completely out of the water.
I am conscious that you have already explained to me (twice!) that Mr
O's approach is aimed not at overturning the overarching
indecidability proof but a mere detail of Linz's proof.
Unfortunately, your explanations have not managed to establish a firm
root in what passes for my brain. This may be because I'm too dense
to grok them, or possibly it's because your explanations are TOAST
(see above).
I generally think I post way too much, and tend to wander off topic
with unnecessary background and so on, and probably I write too much
from a "maths" perspective, because that's my background. Not sure if
I can change any of that! :)Â Just ask if I use obscure notation or
let me know if I'm going too fast/slow. Part of the problem is I
don't know your background and what things you're super familiar with.
You have said, I think, that Olcott doesn't need a universal decider
in order to prove his point. But a less ambitious decider doesn't
contradict Linz's proof, surely? So once more for luck, what exactly
would PO be establishing with his non-universal and impatient
simulator if he could only get it to work?
Yes. PO is aiming to refute the /proof method/ that Linz (and
similar) proofs use, i.e. to attack the /reasoning/ behind the proof.
In effect, he is saying that his HHH/DD provide a counter-example to
that reasoning. His HHH/DD are not full halt deciders - they're /
partial/ halt deciders but that would be enough. I cover what a
partial HD is below, and why it is enough for his argument [..if HHH/
DD worked as originally claimed..]
If he was successful with his HHH/DD programs, it would mean the Linz
proof contained some logical error, and so the conclusion of the proof
(the HP theorem) would not be warranted /by that proof/, We would have
to cross that proof out of our Master Book Of Mathematical Theorems
And Their Proofs! As there are other proofs of the theorem, the
theorem itself could remain.
It would be like the following scenario:Â there are many alternative
proofs of Pythagorus' Theorem, but let's imagine that one of them -
the "MikeT" proof - is the first one taught to all school children
across the world, and it's been that way for the last 50 years.
Suddenly PO finds a flaw in that proof! Sure, there are other proofs
without that flaw so we still trust Pythagorus' Theorem, but we're not
going to continue teaching children an incorrect proof of it, right.
So finding such a flaw would force many changes on our education
system and be highly interesting in its own right.
This doesn't explain exactly how PO's HHH/DD would "refute" the Linz
proof, so that's what the rest of the post tries to do.
The two proofs are isomorphic to each other.
DD correctly emulated by HHH cannot possibly reach its own
emulated "return instruction" final halt state.
⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly
reach its own simulated final halt state ⟨Ĥ.qn⟩
BTW, when I refer to "the Linz proof" it is purely because the Linz
book is apparently the one that PO has access to, and when he started
posting here he claimed to have refuted the "Linz" proof that appears
in that book. As you suspect, the proof is nothing to do with Linz
other than appearing in his book!
That Linz uses explicit state transitions transforms
the alternative vague proofs into an exactingly precise
formal specification.
It also appears I expect in some form in most computer science books
covering computation theory, because it's so well known. Hmm, not
sure who discovered it, but it would be one of the big guys like
Turing, Church, Kleene,... all doing related work in the early days of
the field.
----------------------
So to say what PO's code would refute, I need to explain exactly how
the Linz proof works. Sorry if you already perfectly clear on that!
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
 or
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly
reach its own simulated final halt state ⟨Ĥ.qn⟩
Professor Sipser never took the time to understand
the simple idea of recursive simulation.
On 04/05/2025 19:57, Mike Terry wrote:...
[Hmm, I think that was Malcolm McLean who hasn't posted for a couple of
years.]
I hope he's okay. (Malcolm and I have crossed many swords and we rarely agreed, but I recall him being a most well-mannered and personable
fellow.
As explained above, UTM(⟨Ĥ⟩ ⟨Ĥ⟩) simulates Ĥ run with input Ĥ (having the
same halting behaviour) and Ĥ run with input Ĥ HALTS. So embedded_H does not "gather enough information to deduce that UTM(⟨Ĥ⟩ ⟨Ĥ⟩) would never
halt". THAT IS JUST A FANTASY THAT YOU HAVE.
UTM(⟨Ĥ⟩ ⟨Ĥ⟩) DOES halt, so embedded_H can't possibly gather information
that genuinely implies it DOESN'T halt. The explanation is obvious: embedded_H gathers information that *YOU* believe implies that UTM(⟨Ĥ⟩ ⟨Ĥ⟩)
would never halt, but *YOU ARE SIMPLY WRONG*.
I know you'll not understand what I've just said, because it is all too abstract and you don't understand the concepts involved, and consequently
you probably don't agree with my Sipser interpretation, and even if you did
I doubt you would be able to work out its consequences. So I don't expect
to be posting any further.
On 04/05/2025 19:57, Mike Terry wrote:
<snip>
It was more how much maths background you have
+ familiarity with HP proof you have.
Sorry for the noise, then.
Very little. I rattled through the first ten years easily enough, but I hit a hard wall (integration
by parts) and never really recovered. Such mathematics as I have picked up since has mostly been
through popularisers such as Martin Gardner, Ian Stewart, and Douglas Hofstadter. I think it was in
Hofstadter that I first learned of the Halting Problem.
<snip>
What's to stop the partial decider from deciding pseudorandomly? For example: hashing the input
tapes and deciding according to the hash modulo 2? This would:
1) always decide (as required);
2) sometimes get it right (as required);
3) sometimes get it wrong (as required if it's to be only 'partial');
No, partial halt deciders [*PHD*s] aren't supposed to get it wrong!
We must distinguish carefully between PHDs and PhDs (although, come to think of it, PhDs aren't
supposed to get it wrong either).
But... okay, I'll read on...
If they don't know the answer they're supposed to never answer, but if they do answer [i.e. HALTS
or NEVER_HALTS] it must be right. We could define PHDs so that they have a 3rd answer DONT_KNOW,
but assuming we still allow them to never answer I don't see that the DONT_KNOW answer adds much.
[the new PHDs would be equivalent to my definition]
If they never answer, how long do we wait for nothing to happen?
If we add a DONT_KNOW answer, and then insist the PHD must halt with one of the 3 answers, I think
that would be a different concept, because a PHD might be searching for a particular test
condition and never find it. That would be an infinite loop, which I consider reasonable, but if
it is forced instead to decide DONT_KNOW in finite time, then such a potentially unending search
would be excluded. So I think we have a different concept of PHD now.
I've got my wallet in my hand, but I'm not quite ready yet to buy a PHD that doesn't answer.
DONT_KNOW is conceptually easier to swallow (even though the mileage doesn't look all that great).
Actually, while I've talked about PHDs which are not allowed to decide incorrectly, in fact for
PO's purposes it wouldn't matter if we allowed PHDs to decide inputs incorrectly like you're
imagining. We could be talking about a new type of TM, maybe call it a "Putative PHD" [*PPHD*]
which takes the (P,I) input, and may decide HALTS/NEVER_HALTS or never decide, and PPHDs have no
requirement to answer correctly. [PO's HHH is really a PPHD, not a PHD as it sometimes answers
incorrectly]
Which raises the question of why he bothers.
Everything I've said about PHD's in relation to PO's claims to refute Linz, would work equally
well with PPHDs! That's because all that really matters for PO is that the ONE SPECIFIC INPUT
(<H^>,<H^>) must be decided correctly. It's still the case, even for PPHDs, that the reasoning
used in the Linz proof implies that if H is a PPHD, H will NOT decide input (<H^>,<H^>) correctly.
So if PO could provides even a PPHD H that decides (<H^>,<H^>) /correctly/ that shows a problem
with the Linz proof logic. [Of course, PO cannot provide such an H.]
Well, it's not hard. Scaffolding first (not for publication):
1) he writes H(P,D), which hashes P and D (md5 hash, say? Or even just add up the bits!) and returns
mod 2 of the result, interpreting 0 as 'loops' and 1 as 'halts'
2) he waves Turing's magic wand and sees whether he gets the result he needs for (<H^><H^>).
3) if so, great! But if not, he reverses the meanings of 0 and 1.
4) remove from the docs all signs of fiddling the mod 2 meanings.
Having 'tuned' his PPHD, he can now publish and claim his place in history.
On 5/4/2025 2:13 PM, Richard Heathfield wrote:
On 04/05/2025 18:38, olcott wrote:
<snip>
int sum(int x, int y) { return x + y; }
The mapping from sum(3,2) to sum 5 + 6 does not
exist
That's meaningless. Addition maps two ordinary numbers onto one
number. The mapping of 3 + 2 is to 5, and the mapping of 5 + 6 is to
11. sum(3,2) is the notation of a programming language's function
call, not a mapping. Are you confusing 'computable function' with
'programming language procedure'?
for the same reason that the mapping from DD correctly
simulated by HHH to DD(DD) does not exist.
So you're saying that HHH cannot correctly simulate DD? I agree.
Yes and int sum(int x, int y) { return x + y; }
can not have sum(3,2) return the sum of 5 + 7 for the same reason.
Computable functions
REPORT ON WHAT THEIR INPUT ACTUALLY SPECIFIES
not some twisted delusion.
On 5/4/2025 11:21 AM, Richard Heathfield wrote:
On 04/05/2025 17:06, olcott wrote:
<snip>
They simply guess that because DD(DD) halts that
DD correctly simulated by HHH must also halt.
It's not a guess. If direct execution halts, so must the simulation.
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local
[00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
Maybe you are confused between halting (reaching
a final halt state and terminating normally)
with stopping running for any reason such as
an aborted emulation. *THEY ARE NOT THE SAME*
Richard Heathfield <rjh@cpax.org.uk> writes:
On 04/05/2025 19:57, Mike Terry wrote:...
 [Hmm, I think that was Malcolm McLean who hasn't posted for a couple of >>> years.]
I hope he's okay. (Malcolm and I have crossed many swords and we rarely
agreed, but I recall him being a most well-mannered and personable
fellow.
He was very seriously ill the last time he posted in comp.lang.c. I
fear the worst. None of his GIT projects have had any activity for
nearly a year.
On 5/4/2025 12:06 PM, olcott wrote:
On 5/3/2025 4:28 PM, dbush wrote:
On 5/3/2025 3:45 PM, Richard Heathfield wrote:
I am conscious that you have already explained to me (twice!) that Mr
O's approach is aimed not at overturning the overarching indecidability >>>> proof but a mere detail of Linz's proof. Unfortunately, your
explanations have not managed to establish a firm root in what passes
for my brain. This may be because I'm too dense to grok them, or
possibly it's because your explanations are TOAST (see above).
You have said, I think, that Olcott doesn't need a universal decider in >>>> order to prove his point. But a less ambitious decider doesn't
contradict Linz's proof, surely? So once more for luck, what exactly
would PO be establishing with his non-universal and impatient simulator >>>> if he could only get it to work?
The core issue is that PO, despise being nearly 70 and having worked as
a programmer, fundamentally doesn't understand proof by contradiction.
The actual issue is the NO ONE here (or perhaps anywhere)
sufficiently understands the key details about
COMPUTING THE MAPPING FROM AN INPUT TO AN OUTPUT.
Many here know that a mapping from the input must be
computed.
False. There is no requirement that a mapping is computable. The
halting function is one such mapping, as Linz and others have proved
and you have *explictly* agreed is correct.
What they don't know are ALL of the tiny
detailed steps required to compute this mapping.
And if the mapping isn't computable, like the halting function, there
are no such steps.
They simply guess that because DD(DD) halts that
DD correctly simulated by HHH must also halt.
A correct simulation is stipulated to be one that exactly matches the behavior of the machine to be simulated.
DD is not correctly simulated by HHH, as the last instruction simulated
is not simulated correctly, because the x86 language requires any
executed instruction other than a HLT to be followed by the execution
of the next instruction.
We also know that "DD correctly simulated by HHH" is PO-speak for
"Replacing the code of HHH with an unconditional simulator and
subsequently running HHH(DD)", as you have agreed and given permission
to replace the former with the later.
This means that you're changing the input.
Changing the input is not allowed.
They cannot provide these detailed steps of the
execution trace of each machine instruction showing
exactly how DD correctly emulated by HHH halts
BECAUSE THEY KNOW THAT THEY ARE WRONG AND ONLY PLAYING HEAD GAMES.
That you don't understand requirements doesn't make it a head game.
On 04/05/2025 22:18, Richard Heathfield wrote:
[Of course, PO cannot provide such an H.]
Well, it's not hard. Scaffolding first (not for publication):
1) he writes H(P,D), which hashes P and D (md5 hash, say? Or
even just add up the bits!) and returns mod 2 of the result,
interpreting 0 as 'loops' and 1 as 'halts'
2) he waves Turing's magic wand and sees whether he gets the
result he needs for (<H^><H^>).
3) if so, great! But if not, he reverses the meanings of 0 and 1.
4) remove from the docs all signs of fiddling the mod 2 meanings.
Having 'tuned' his PPHD, he can now publish and claim his place
in history.
Ah, that's not what I thought you were thinking.
What you're suggesting doesn't work! Remember the order
PO likes to imagine that there's something Wrong with H^ or H2^
which warrants them being excluded from HP or treated differently
re. definition of halting etc.. Normally he does that by
pretending that H and H1 are "one machine", and "whichever
decision that machine makes it will be wrong!!", so we have
Pathelogical Self Refernce or some kind of paradox or what not.
Thinking clearly as above (and giving distinct names for distinct
objects helps) makes it clear he's just muddling things up.
On 5/3/2025 7:20 PM, Mike Terry wrote:
On 03/05/2025 20:45, Richard Heathfield wrote:
On 03/05/2025 19:50, Mike Terry wrote:
On 03/05/2025 06:47, Richard Heathfield wrote:
<snip>
In passing, when I nailed down "TL;DR" I felt mildly guilty for
scoring so few tersinosity points, but in return I must accuse you
of undue obscurity.
TL;DR appears to have attracted a certain currency, so okay, but...
NTLFM? Really? "Seek and ye shall find", so I sought but shall
findethed not. Most of my best guesses started 'Now The' and ended
rhyming with RTFM, but none of those guesses jumped out as being
self-evidently right. Would you care to translate?
I admit to making it up, but all these (usenet?) abbreviations have
to start somewhere, so I thought I would start a much needed new one!
TL;DR = too long, didn't read,
Yes, that chimes with my research, but...
introducing a short summary for someone who hasn't the inclination/
time to read a long (probably overly) verbose explanation. At least
that's how I've seen it used. But then, how to introduce the
verbose explanation? I couldn't find anything for that, so I
invented NTLFM; which means "Not Too Long For Me" !
Ach! Of course.
I'm looking forward to being a footnote in history when it catches
on...
In a footnote to the footnote for NTLFM I would add TOAST --- Too
Obscure And Startlingly Terse.
I kind of disagree with your mild denigration of the Linz (and
similar) proofs.
I wish to clarify that denigration was most certainly not my
intent. There is, however, no doubt in my mind that while Linz is
undoubtedly a worthy and indeed admirable computer scientist, his
proof stands on giant shoulders. All I meant to say was that, were
Linz's proof to lose its balance and take a tumble, it would not be
the fault of the shoulders.
Yeah, denigration was really the wrong word, as I know there was no
bad intent anywhere. Perhaps "downplaying" would have been what I
was looking for.
<nod />
Ben pointed out there was confusion in the Linz proof with the
labelling of states, and when I looked closely at the proof I a few
years ago I recall thinking Linz had munged the conversion of
(general) TM tape inputs to "H inputs" (which in Linz are binary
representations of those tapes) when duplicating D's input. Now I'm
not sure about that, but can't motivate myself to get to the bottom
of it, since either way, if it is a problem it's clear how it should
be fixed, and the basis for the proof is not affected.
The proof is both "very easy" conceptually [as witnessed by how many
people join in here, quickly understanding how it works if they've
not come across it before], and slightly fiddly due to the TM H
needing to have a fixed tape alphabet which must be able to
represent any TM as well as any tape input for that TM. So there
are certainly opportunities to miss details especially with a book
aimed at those with a minimal maths background. Really, the only
aspect of the proof requiring careful thought is convincing yourself
that the fiddliness has been handled ok, along with understanding
the notation used...
I don't see any scope for the proof actually being invalid, and PO
certainly does not present any argument for it being invalid. He
simply believes his H can give the right answer for his D, and
that's the beginning and end of it all. When he developed his
x96utm, it became possible to actually run his code, and it became /
manifestly/ clear his H gets the wrong answer for D. But PO just
doubles down and comes up with bizarre explanations for why he still
thinks it is right when it is obviously wrong.
As I re-read Linz /again/, two points stick out:
"We cannot find the answer by simulating the action of M on w, say by
performing it on a universal Turing machine, because there is no
limit on the length of the computation. If M enters an infinite loop,
then no matter how long we wait, we can never be sure that M is in
fact in a loop. It may simply be a case of a very long computation.
What we need is an algorithm that can determine the correct answer
for any M and w by performing some
analysis on the machine's description and the input. But as we
now show, no such algorithm exists."
"It is important to keep in mind what Theorem 12.1 says. It does not
preclude solving the halting problem for specific cases; often we can
tell by an analysis of M and w whether or not the Turing machine will
halt. What the theorem says is that this cannot always be done; there
is no algorithm that can make a correct decision for all WM and w."
Both of these statements are self-evidently true, and both would
appear to knock Mr O's HHH completely out of the water.
I am conscious that you have already explained to me (twice!) that Mr
O's approach is aimed not at overturning the overarching
indecidability proof but a mere detail of Linz's proof.
Unfortunately, your explanations have not managed to establish a firm
root in what passes for my brain. This may be because I'm too dense
to grok them, or possibly it's because your explanations are TOAST
(see above).
I generally think I post way too much, and tend to wander off topic
with unnecessary background and so on, and probably I write too much
from a "maths" perspective, because that's my background.
Not so much programming background?
Not sure if I can change any of that! :)Â Just ask if I use obscure
notation or let me know if I'm going too fast/slow. Part of the
problem is I don't know your background and what things you're super
familiar with.
You have said, I think, that Olcott doesn't need a universal decider
in order to prove his point. But a less ambitious decider doesn't
contradict Linz's proof, surely? So once more for luck, what exactly
would PO be establishing with his non-universal and impatient
simulator if he could only get it to work?
Yes. PO is aiming to refute the /proof method/ that Linz (and
similar) proofs use, i.e. to attack the /reasoning/ behind the proof.
In effect, he is saying that his HHH/DD provide a counter-example to
that reasoning. His HHH/DD are not full halt deciders - they're /
partial/ halt deciders but that would be enough.
Or we could call them their software engineering name
of "termination analyzers".
 I cover what a partial HD is
below, and why it is enough for his argument [..if HHH/DD worked as
originally claimed..]
If he was successful with his HHH/DD programs, it would mean the Linz
proof contained some logical error, and so the conclusion of the proof
(the HP theorem) would not be warranted /by that proof/, We would have
to cross that proof out of our Master Book Of Mathematical Theorems
And Their Proofs! As there are other proofs of the theorem, the
theorem itself could remain.
It would be like the following scenario:Â there are many alternative
proofs of Pythagorus' Theorem, but let's imagine that one of them -
the "MikeT" proof - is the first one taught to all school children
across the world, and it's been that way for the last 50 years.
Suddenly PO finds a flaw in that proof! Sure, there are other proofs
without that flaw so we still trust Pythagorus' Theorem, but we're not
going to continue teaching children an incorrect proof of it, right.
So finding such a flaw would force many changes on our education
system and be highly interesting in its own right.
This doesn't explain exactly how PO's HHH/DD would "refute" the Linz
proof, so that's what the rest of the post tries to do.
BTW, when I refer to "the Linz proof" it is purely because the Linz
book is apparently the one that PO has access to, and when he started
posting here he claimed to have refuted the "Linz" proof that appears
in that book. As you suspect, the proof is nothing to do with Linz
other than appearing in his book! It also appears I expect in some
form in most computer science books covering computation theory,
because it's so well known. Hmm, not sure who discovered it, but it
would be one of the big guys like Turing, Church, Kleene,... all doing
related work in the early days of the field.
----------------------
So to say what PO's code would refute, I need to explain exactly how
the Linz proof works. Sorry if you already perfectly clear on that!
Say I give you a halt decider H. H is a TM, and following the
mechanical instructions in Linz, you would be able to create from H a
new TM H^. Basically you start with the H I gave, and edit it:
1) add some initial code that runs before my H gets control - that
code duplicates whatever input is on the tape when it is invoked, so
that if the initial tape contained "hello\0" the modified tape needs
to end up "hello\0hello\0".
2) modify the halt states that my H used to indicate halt/non-halting
when deciding its input:
   - the state H uses to indicate its input halts is replaced with a >> tight loop
   - the state H uses to indicate its input fails to halt is
replaced with halt state.
      Hmm, that state was a halt state in the H I gave you, so
actually there's no change
      for that state.
So, I gave you H, and you've modified it to produce a new TM H^. The
essence of the Linz proof is that the logic of how H^ works /
guarantees/ that when we ask my H whether your H^ halts when run
against a tape containing the TM-description of H^, my H will give the
wrong answer! So, my H never was a halt decider after all, because it
gets a wrong answer for this particular input. Halt deciders must
decide halting correctly for /every/ input i.e. every combination of
P,IÂ [P is the TM, I the input tape].
[I'm not explaining the proof of /why/ H will get the answer wrong.
That's important of course and is in Linz and other accounts of the
proof, but it's not really relevant to understanding what PO is trying
to achieve.]
This next bit might be a missing key for you...   Looking at the
above, we started by me giving you a "halt decider" H. What if I only
gave you a lesser achievement: a "partial halt decider" that correctly
decides halting for certain (P,I) inputs, but fails to halt for all
the rest? The answer is the same logic still applies, but the
conclusion is slightly different:
-Â I give you a /partial/ HDÂ H
-Â You follow the same instructions to create the new TM, H^
-Â The same reasoning of the Linz proof shows that my H does not
correctly decide halting
   for the case of TM H^ running against input <H^>
   a) If H decides HALTS, we can show H^(<H^>) never halts
   b) If H decides NEVER_HALTS, we can show H^(<H^>) halts
   c) If H fails to decide (i.e. it loops) then H^(<H^>) never halts >>        This last possibility is new, because H is only a partial halt
decider
Now we can look at what PO claims to have: a *partial* halt decider H,
which CORRECTLY decides its corresponding input (<H^>,<H^>).
Specifically, he claims his H decides NEVER_HALTS, and that indeed
H^(<H^>) never halts. This contradicts the Linz proof /reasoning/
which lead to (b) above.
Since the Linz proof reasoning would have been shown to reach a false
conclusion [in the case of PO's HHH/DD programs], the reasoning must
be wrong somewhere, and if the reasoning is wrong it can't be used in
the Linz proof. It is ok here that H is only a partial halt decider -
in fact the above only requires that PO's H correctly decides the one
H^(<H^>) case to get the contradiction.
Er, that's it!
Just as a reminder I'll repeat the final outcome of all this:
-Â PO's H does decide NEVER_HALTS for TM H^ running with input <H^>.
-Â PO's H^ running with input <H^> in fact halts, in line with Linz
logic (b) above.
A final observation - nothing in this post is anything to do with
"simulation". That comes later looking at how PO's H supposedly works... >>
Mike.
On 5/4/2025 8:04 PM, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
...
As explained above, UTM(⟨Ĥ⟩ ⟨Ĥ⟩) simulates Ĥ run with input Ĥ (having
the
same halting behaviour) and Ĥ run with input Ĥ HALTS. So embedded_H
does
not "gather enough information to deduce that UTM(⟨Ĥ⟩ ⟨Ĥ⟩) would never
halt". THAT IS JUST A FANTASY THAT YOU HAVE.
UTM(⟨Ĥ⟩ ⟨Ĥ⟩) DOES halt, so embedded_H can't possibly gather information
that genuinely implies it DOESN'T halt. The explanation is obvious:
embedded_H gathers information that *YOU* believe implies that
UTM(⟨Ĥ⟩ ⟨Ĥ⟩)
would never halt, but *YOU ARE SIMPLY WRONG*.
He used to claim that false ("does not halt") was the correct answer,
/even though/ the computation in question halts! Those were simpler
days. Of course cranks will never admit to having been wrong about
anything other than a detail or two, so anyone who could be bothered
could try to get him to retract that old claim.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
   If simulating halt decider H correctly simulates its input D
   until H correctly determines that its simulated D would never
   stop running unless aborted then
   H can abort its simulation of D and correctly report that D
   specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
In other words embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ is correct to
reject its input if
Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Would not halt.
I know you'll not understand what I've just said, because it is all too
abstract and you don't understand the concepts involved, and
consequently
you probably don't agree with my Sipser interpretation, and even if
you did
I doubt you would be able to work out its consequences. So I don't
expect
to be posting any further.
Not you then! I sympathise, though my reason for not talking to him is
his unacceptable insults.
On 5/4/2025 9:58 PM, dbush wrote:
On 5/4/2025 9:23 PM, olcott wrote:
On 5/4/2025 8:04 PM, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
...
As explained above, UTM(⟨Ĥ⟩ ⟨Ĥ⟩) simulates Ĥ run with input Ĥ >>>>> (having the
same halting behaviour) and Ĥ run with input Ĥ HALTS. So
embedded_H does
not "gather enough information to deduce that UTM(⟨Ĥ⟩ ⟨Ĥ⟩) would never
halt". THAT IS JUST A FANTASY THAT YOU HAVE.
UTM(⟨Ĥ⟩ ⟨Ĥ⟩) DOES halt, so embedded_H can't possibly gather >>>>> information
that genuinely implies it DOESN'T halt. The explanation is obvious: >>>>> embedded_H gathers information that *YOU* believe implies that
UTM(⟨Ĥ⟩ ⟨Ĥ⟩)
would never halt, but *YOU ARE SIMPLY WRONG*.
He used to claim that false ("does not halt") was the correct answer,
/even though/ the computation in question halts! Those were simpler
days. Of course cranks will never admit to having been wrong about
anything other than a detail or two, so anyone who could be bothered
could try to get him to retract that old claim.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
    If simulating halt decider H correctly simulates its input D
    until H correctly determines that its simulated D would never
    stop running unless aborted then
    H can abort its simulation of D and correctly report that D
    specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
And you *CONTINUE* to lie by implying that Sipser agrees with you when
it's been repeated proven that he does not:
On Monday, March 6, 2023 at 2:41:27 PM UTC-5, Ben Bacarisse wrote:
I exchanged emails with him about this. He does not agree withanything
substantive that PO has written. I won't quote him, as I don't have
permission, but he was, let's say... forthright, in his reply to me.
This demonstrates a reckless disregard for the truth on your part.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
In other words embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ is correct to
reject its input if
Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Would not halt.
In other words, you change the input.
Changing the input is not allowed.
D *WOULD NEVER STOP RUNNING UNLESS*
indicates that professor Sipser was agreeing
to hypotheticals AS *NOT CHANGING THE INPUT*
You are taking
*WOULD NEVER STOP RUNNING UNLESS*
to mean *NEVER STOPS RUNNING* that is incorrect.
On 5/5/2025 8:23 PM, Richard Damon wrote:
On 5/4/25 9:23 PM, olcott wrote:
On 5/4/2025 8:04 PM, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
...
As explained above, UTM(⟨Ĥ⟩ ⟨Ĥ⟩) simulates Ĥ run with input Ĥ >>>>> (having the
same halting behaviour) and Ĥ run with input Ĥ HALTS. So
embedded_H does
not "gather enough information to deduce that UTM(⟨Ĥ⟩ ⟨Ĥ⟩) would never
halt". THAT IS JUST A FANTASY THAT YOU HAVE.
UTM(⟨Ĥ⟩ ⟨Ĥ⟩) DOES halt, so embedded_H can't possibly gather >>>>> information
that genuinely implies it DOESN'T halt. The explanation is obvious: >>>>> embedded_H gathers information that *YOU* believe implies that
UTM(⟨Ĥ⟩ ⟨Ĥ⟩)
would never halt, but *YOU ARE SIMPLY WRONG*.
He used to claim that false ("does not halt") was the correct answer,
/even though/ the computation in question halts! Those were simpler
days. Of course cranks will never admit to having been wrong about
anything other than a detail or two, so anyone who could be bothered
could try to get him to retract that old claim.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
    If simulating halt decider H correctly simulates its input D
    until H correctly determines that its simulated D would never
    stop running unless aborted then
    H can abort its simulation of D and correctly report that D
    specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
In other words embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ is correct to
reject its input if
Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Would not halt.
Nope, because that isn't the input that it was given.
*Wrong*
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
   If simulating halt decider H correctly simulates its input D
   until H correctly determines that its *simulated D would never*
   *stop running unless aborted* then
*simulated D would never stop running unless aborted*
simulated D (the actual input)
never stop running unless aborted (hypothetical H/D pair)
On 5/6/2025 6:23 AM, Richard Damon wrote:
On 5/5/25 10:36 PM, olcott wrote:
On 5/5/2025 8:23 PM, Richard Damon wrote:
On 5/4/25 9:23 PM, olcott wrote:
On 5/4/2025 8:04 PM, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
...
As explained above, UTM(⟨Ĥ⟩ ⟨Ĥ⟩) simulates Ĥ run with input Ĥ
(having the
same halting behaviour) and Ĥ run with input Ĥ HALTS. So
embedded_H does
not "gather enough information to deduce that UTM(⟨Ĥ⟩ ⟨Ĥ⟩) would
never
halt". THAT IS JUST A FANTASY THAT YOU HAVE.
UTM(⟨Ĥ⟩ ⟨Ĥ⟩) DOES halt, so embedded_H can't possibly gather >>>>>>> information
that genuinely implies it DOESN'T halt. The explanation is obvious: >>>>>>> embedded_H gathers information that *YOU* believe implies that
UTM(⟨Ĥ⟩ ⟨Ĥ⟩)
would never halt, but *YOU ARE SIMPLY WRONG*.
He used to claim that false ("does not halt") was the correct answer, >>>>>> /even though/ the computation in question halts! Those were simpler >>>>>> days. Of course cranks will never admit to having been wrong about >>>>>> anything other than a detail or two, so anyone who could be bothered >>>>>> could try to get him to retract that old claim.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> Â Â Â Â If simulating halt decider H correctly simulates its input D >>>>> Â Â Â Â until H correctly determines that its simulated D would never >>>>> Â Â Â Â stop running unless aborted then
    H can abort its simulation of D and correctly report that D >>>>>     specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
In other words embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ is correct to
reject its input if
Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Would not halt.
Nope, because that isn't the input that it was given.
*Wrong*
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
    If simulating halt decider H correctly simulates its input D
    until H correctly determines that its *simulated D would never* >>>     *stop running unless aborted* then
*simulated D would never stop running unless aborted*
simulated D (the actual input)
never stop running unless aborted (hypothetical H/D pair)
No, that is changing the input.
*would never stop running unless aborted*
means the hypothetical same HHH that DD calls
except that this HHH does not abort.
On 5/6/2025 6:23 AM, Richard Damon wrote:Yes, that is not the same HHH.
On 5/5/25 10:36 PM, olcott wrote:*would never stop running unless aborted* means the hypothetical same
On 5/5/2025 8:23 PM, Richard Damon wrote:No, that is changing the input.
On 5/4/25 9:23 PM, olcott wrote:
On 5/4/2025 8:04 PM, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:<MIT Professor Sipser agreed to ONLY these verbatim words
...
As explained above, UTM(⟨Ĥ⟩ ⟨Ĥ⟩) simulates Ĥ run with input Ĥ
(having the same halting behaviour) and Ĥ run with input Ĥ HALTS. >>>>>>> So embedded_H does not "gather enough information to deduce that >>>>>>> UTM(⟨Ĥ⟩ ⟨Ĥ⟩) would never halt". THAT IS JUST A FANTASY THAT YOU
HAVE.
UTM(⟨Ĥ⟩ ⟨Ĥ⟩) DOES halt, so embedded_H can't possibly gather >>>>>>> information that genuinely implies it DOESN'T halt. The
explanation is obvious: embedded_H gathers information that *YOU* >>>>>>> believe implies that UTM(⟨Ĥ⟩ ⟨Ĥ⟩)
would never halt, but *YOU ARE SIMPLY WRONG*.
He used to claim that false ("does not halt") was the correct
answer,
/even though/ the computation in question halts! Those were
simpler days. Of course cranks will never admit to having been
wrong about anything other than a detail or two, so anyone who
could be bothered could try to get him to retract that old claim.
10/13/2022>
</MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
In other words embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ is correct to reject its input if
Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn Would not halt.
Nope, because that isn't the input that it was given.
*Wrong*
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
    If simulating halt decider H correctly simulates its input D
    until H correctly determines that its *simulated D would
    never stop running unless aborted* then
*simulated D would never stop running unless aborted*
simulated D (the actual input)
never stop running unless aborted (hypothetical H/D pair)
HHH that DD calls except that this HHH does not abort.
On 5/6/2025 6:23 AM, Richard Damon wrote:
On 5/5/25 10:36 PM, olcott wrote:
On 5/5/2025 8:23 PM, Richard Damon wrote:
On 5/4/25 9:23 PM, olcott wrote:
On 5/4/2025 8:04 PM, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
...
As explained above, UTM(⟨Ĥ⟩ ⟨Ĥ⟩) simulates Ĥ run with input Ĥ
(having the
same halting behaviour) and Ĥ run with input Ĥ HALTS. So
embedded_H does
not "gather enough information to deduce that UTM(⟨Ĥ⟩ ⟨Ĥ⟩) would
never
halt". THAT IS JUST A FANTASY THAT YOU HAVE.
UTM(⟨Ĥ⟩ ⟨Ĥ⟩) DOES halt, so embedded_H can't possibly gather >>>>>>> information
that genuinely implies it DOESN'T halt. The explanation is obvious: >>>>>>> embedded_H gathers information that *YOU* believe implies that
UTM(⟨Ĥ⟩ ⟨Ĥ⟩)
would never halt, but *YOU ARE SIMPLY WRONG*.
He used to claim that false ("does not halt") was the correct answer, >>>>>> /even though/ the computation in question halts! Those were simpler >>>>>> days. Of course cranks will never admit to having been wrong about >>>>>> anything other than a detail or two, so anyone who could be bothered >>>>>> could try to get him to retract that old claim.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> Â Â Â Â If simulating halt decider H correctly simulates its input D >>>>> Â Â Â Â until H correctly determines that its simulated D would never >>>>> Â Â Â Â stop running unless aborted then
    H can abort its simulation of D and correctly report that D >>>>>     specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
In other words embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ is correct to
reject its input if
Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Would not halt.
Nope, because that isn't the input that it was given.
*Wrong*
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
    If simulating halt decider H correctly simulates its input D
    until H correctly determines that its *simulated D would never* >>>     *stop running unless aborted* then
*simulated D would never stop running unless aborted*
simulated D (the actual input)
never stop running unless aborted (hypothetical H/D pair)
No, that is changing the input.
*would never stop running unless aborted*
means the hypothetical same HHH that DD calls
except that this HHH does not abort.
On 5/6/2025 2:01 PM, Fred. Zwarts wrote:
Op 06.mei.2025 om 19:49 schreef olcott:
On 5/6/2025 6:23 AM, Richard Damon wrote:
On 5/5/25 10:36 PM, olcott wrote:
On 5/5/2025 8:23 PM, Richard Damon wrote:
On 5/4/25 9:23 PM, olcott wrote:
On 5/4/2025 8:04 PM, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes: >>>>>>>> ...
As explained above, UTM(⟨Ĥ⟩ ⟨Ĥ⟩) simulates Ĥ run with input Ĥ
(having the
same halting behaviour) and Ĥ run with input Ĥ HALTS. So >>>>>>>>> embedded_H does
not "gather enough information to deduce that UTM(⟨Ĥ⟩ ⟨Ĥ⟩) >>>>>>>>> would never
halt". THAT IS JUST A FANTASY THAT YOU HAVE.
UTM(⟨Ĥ⟩ ⟨Ĥ⟩) DOES halt, so embedded_H can't possibly gather >>>>>>>>> information
that genuinely implies it DOESN'T halt. The explanation is >>>>>>>>> obvious:
embedded_H gathers information that *YOU* believe implies that >>>>>>>>> UTM(⟨Ĥ⟩ ⟨Ĥ⟩)
would never halt, but *YOU ARE SIMPLY WRONG*.
He used to claim that false ("does not halt") was the correct
answer,
/even though/ the computation in question halts! Those were
simpler
days. Of course cranks will never admit to having been wrong about >>>>>>>> anything other than a detail or two, so anyone who could be
bothered
could try to get him to retract that old claim.
<MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
    If simulating halt decider H correctly simulates its input D >>>>>>>     until H correctly determines that its simulated D would never >>>>>>>     stop running unless aborted then
    H can abort its simulation of D and correctly report that D >>>>>>>     specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
In other words embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ is correct to
reject its input if
Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Would not halt.
Nope, because that isn't the input that it was given.
*Wrong*
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> Â Â Â Â If simulating halt decider H correctly simulates its input D >>>>> Â Â Â Â until H correctly determines that its *simulated D would never* >>>>> Â Â Â Â *stop running unless aborted* then
*simulated D would never stop running unless aborted*
simulated D (the actual input)
never stop running unless aborted (hypothetical H/D pair)
No, that is changing the input.
*would never stop running unless aborted*
means the hypothetical same HHH that DD calls
except that this HHH does not abort.
Which makes it a fundamentally different HHH.
None-the-less it is the words that the best selling
author of theory of computation textbooks agreed to:
*would never stop running unless aborted*
is the hypothetical HHH/DD pair where the same HHH
that DD calls does not abort the simulation of its input.
On 5/6/2025 3:25 PM, joes wrote:
Am Tue, 06 May 2025 12:49:13 -0500 schrieb olcott:
On 5/6/2025 6:23 AM, Richard Damon wrote:Yes, that is not the same HHH.
On 5/5/25 10:36 PM, olcott wrote:*would never stop running unless aborted* means the hypothetical same
On 5/5/2025 8:23 PM, Richard Damon wrote:No, that is changing the input.
On 5/4/25 9:23 PM, olcott wrote:
On 5/4/2025 8:04 PM, Ben Bacarisse wrote:Nope, because that isn't the input that it was given.
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes: >>>>>>>> ...<MIT Professor Sipser agreed to ONLY these verbatim words
As explained above, UTM(⟨Ĥ⟩ ⟨Ĥ⟩) simulates Ĥ run with input Ĥ
(having the same halting behaviour) and Ĥ run with input Ĥ HALTS. >>>>>>>>> So embedded_H does not "gather enough information to deduce that >>>>>>>>> UTM(⟨Ĥ⟩ ⟨Ĥ⟩) would never halt". THAT IS JUST A FANTASY THAT YOU
HAVE.
UTM(⟨Ĥ⟩ ⟨Ĥ⟩) DOES halt, so embedded_H can't possibly gather >>>>>>>>> information that genuinely implies it DOESN'T halt. The
explanation is obvious: embedded_H gathers information that *YOU* >>>>>>>>> believe implies that UTM(⟨Ĥ⟩ ⟨Ĥ⟩)
would never halt, but *YOU ARE SIMPLY WRONG*.
He used to claim that false ("does not halt") was the correct
answer,
/even though/ the computation in question halts! Those were
simpler days. Of course cranks will never admit to having been >>>>>>>> wrong about anything other than a detail or two, so anyone who >>>>>>>> could be bothered could try to get him to retract that old claim. >>>>>>>>
10/13/2022>
</MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
In other words embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ is correct to reject its input if
Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn Would not halt. >>>>>>
*Wrong*
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> Â Â Â Â Â If simulating halt decider H correctly simulates its input D >>>>> Â Â Â Â Â until H correctly determines that its *simulated D would
     never stop running unless aborted* then
*simulated D would never stop running unless aborted*
simulated D (the actual input)
never stop running unless aborted (hypothetical H/D pair)
HHH that DD calls except that this HHH does not abort.
Yet is the HHH that Professor Sipser agreed would be
the correct measure of the behavior of the actual input.
On 5/6/2025 2:01 PM, Fred. Zwarts wrote:
Op 06.mei.2025 om 19:49 schreef olcott:
On 5/6/2025 6:23 AM, Richard Damon wrote:
On 5/5/25 10:36 PM, olcott wrote:
On 5/5/2025 8:23 PM, Richard Damon wrote:
On 5/4/25 9:23 PM, olcott wrote:
On 5/4/2025 8:04 PM, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes: >>>>>>>> ...
As explained above, UTM(⟨Ĥ⟩ ⟨Ĥ⟩) simulates Ĥ run with input Ĥ
(having the
same halting behaviour) and Ĥ run with input Ĥ HALTS. So >>>>>>>>> embedded_H does
not "gather enough information to deduce that UTM(⟨Ĥ⟩ ⟨Ĥ⟩) >>>>>>>>> would never
halt". THAT IS JUST A FANTASY THAT YOU HAVE.
UTM(⟨Ĥ⟩ ⟨Ĥ⟩) DOES halt, so embedded_H can't possibly gather >>>>>>>>> information
that genuinely implies it DOESN'T halt. The explanation is >>>>>>>>> obvious:
embedded_H gathers information that *YOU* believe implies that >>>>>>>>> UTM(⟨Ĥ⟩ ⟨Ĥ⟩)
would never halt, but *YOU ARE SIMPLY WRONG*.
He used to claim that false ("does not halt") was the correct
answer,
/even though/ the computation in question halts! Those were
simpler
days. Of course cranks will never admit to having been wrong about >>>>>>>> anything other than a detail or two, so anyone who could be
bothered
could try to get him to retract that old claim.
<MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
    If simulating halt decider H correctly simulates its input D >>>>>>>     until H correctly determines that its simulated D would never >>>>>>>     stop running unless aborted then
    H can abort its simulation of D and correctly report that D >>>>>>>     specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
In other words embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ is correct to
reject its input if
Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Would not halt.
Nope, because that isn't the input that it was given.
*Wrong*
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> Â Â Â Â If simulating halt decider H correctly simulates its input D >>>>> Â Â Â Â until H correctly determines that its *simulated D would never* >>>>> Â Â Â Â *stop running unless aborted* then
*simulated D would never stop running unless aborted*
simulated D (the actual input)
never stop running unless aborted (hypothetical H/D pair)
No, that is changing the input.
*would never stop running unless aborted*
means the hypothetical same HHH that DD calls
except that this HHH does not abort.
Which makes it a fundamentally different HHH.
None-the-less it is the words that the best selling
author of theory of computation textbooks agreed to:
*would never stop running unless aborted*
is the hypothetical HHH/DD pair where the same HHH
that DD calls does not abort the simulation of its input.
On 5/7/2025 7:01 AM, dbush wrote:
On 5/7/2025 6:16 AM, Fred. Zwarts wrote:
Op 06.mei.2025 om 21:15 schreef olcott:
None-the-less it is the words that the best selling
author of theory of computation textbooks agreed to:
*would never stop running unless aborted*
is the hypothetical HHH/DD pair where the same HHH
that DD calls does not abort the simulation of its input.
Nevertheless, this change makes it fundamentally different.
I can't believe that you are so stupid to think that modifying a
program does not make a program different. Are you trolling?
Given that he's shown he doesn't understand (and this list is by no
means exhaustive):
* what requirements are
* what correct means
* what true means
* what a proof is
* how proof by contradiction works
I wouldn't put it past him that he actually believes it. He'll say
anything to avoid admitting to himself that he wasted that last 22
years not understanding what he was working on.
(Anyone else that wants to add to this list, feel free)
A simulating halt decider must correctly
predict *what the behavior would be* if it
did not abort its simulation.
On 5/7/2025 7:01 AM, dbush wrote:...if it, the simulator, didn't abort. The input DD that is being
On 5/7/2025 6:16 AM, Fred. Zwarts wrote:
Op 06.mei.2025 om 21:15 schreef olcott:
None-the-less it is the words that the best selling author of theoryNevertheless, this change makes it fundamentally different.
of computation textbooks agreed to: *would never stop running unless
aborted*
is the hypothetical HHH/DD pair where the same HHH that DD calls does
not abort the simulation of its input.
I can't believe that you are so stupid to think that modifying a
program does not make a program different. Are you trolling?
Given that he's shown he doesn't understand (and this list is by no
means exhaustive):
* what requirements are * what correct means * what true means * what a
proof is * how proof by contradiction works
I wouldn't put it past him that he actually believes it. He'll say
anything to avoid admitting to himself that he wasted that last 22
years not understanding what he was working on.
(Anyone else that wants to add to this list, feel free)
A simulating halt decider must correctly predict *what the behavior
would be* if it did not abort its simulation.
*simulated D would never stop running unless aborted*So a non-input.
means that HHH examines what the behavior of DD *would be*
if it never aborted its simulation. This is a different
hypothetical HHH/DD pair than the actual HHH/DD pair.
If it did not do this and simply kept simulating a non-terminating inputIf it does do this it breaks the requirement that it must return the value
it would break the requirement that itself must halt.
HHH did not abort its input. That is the ONLY way that
simulating halt deciders can possibly work.
On 5/7/2025 2:02 PM, Richard Heathfield wrote:
On 07/05/2025 19:47, olcott wrote:
<snip>
HHH did not abort its input. That is the ONLY way that
simulating halt deciders can possibly work.
Another only is that simulating halt deciders (like
code-parsing halt deciders) can only possibly work if they
don't claim to be universal.
That is why I switched to "termination analyzer" as
long as it correctly determines the halt status on one
single input that has no inputs then it is correct.
I don't think it make sense to continue to talk to
clueless people that lack the technical capacity
to verify key facts.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 498 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 35:29:30 |
| Calls: | 9,798 |
| Files: | 13,751 |
| Messages: | 6,189,275 |