On 5/22/2025 8:24 PM, Mike Terry wrote:
On 22/05/2025 06:41, Richard Heathfield wrote:
On 22/05/2025 06:23, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 22/05/2025 00:14, olcott wrote:[...]
On 5/21/2025 6:11 PM, Richard Heathfield wrote:
Turing proved that what you're asking is impossible.That is not what he proved.
Then you'll be able to write a universal termination analyser that can >>>>> correctly report for any program and any input whether it halts. Good >>>>> luck with that.
Not necessarily.
Of course not. But I'm just reflecting. He seemed to think that my
inability to write the kind of program Turing envisaged (an inability
that I readily concede) is evidence for his argument. Well, what's
sauce for the goose is sauce for the gander.
Even if olcott had refuted the proofs of the
insolvability of the Halting Problem -- or even if he had proved
that a universal halt decider is possible
And we both know what we both think of that idea.
-- that doesn't imply
that he or anyone else would be able to write one.
Indeed.
I've never been entirely clear on what olcott is claiming.
Nor I. Mike Terry seems to have a pretty good handle on it, but no
matter how clearly he explains it to me my eyes glaze over and I start
to snore.
Hey, it's the way I tell 'em!
Here's what the tabloids might have said about it, if it had made the
front pages when the story broke:
COMPUTER BOFFIN IS TURING IN HIS GRAVE!
An Internet crank claims to have refuted Linz HP proof by creating a
Halt Decider that CORRECTLY decides its own "impossible input"!
The computing world is underwhelmed.
Better? (Appologies for the headline, it's the best I could come up with.) >>
Mike.
There is a key detail about ALL of these proofs
that no one has paid attention to for 90 years.
It is impossible to define *AN INPUT* to HHH that
does the opposite of whatever value that HHH returns.
On Thu, 2025-05-22 at 21:47 -0500, olcott wrote:
[cut]
Q: How do computations actually work?
A: Computation is merely step-by-step algorithm.
Nothing says it has to be TM.
Do the exercises in textbooks first before any claim of it.
On 5/22/2025 10:23 PM, wij wrote:
On Thu, 2025-05-22 at 21:47 -0500, olcott wrote:
[cut]
Q: How do computations actually work?
A: Computation is merely step-by-step algorithm.
Nothing says it has to be TM.
Do the exercises in textbooks first before any claim of it.
int main()
{
DD(); // by what steps can the HHH that DD calls
} // report on the behavior its caller?
On 5/22/2025 8:24 PM, Mike Terry wrote:
On 22/05/2025 06:41, Richard Heathfield wrote:
On 22/05/2025 06:23, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 22/05/2025 00:14, olcott wrote:[...]
On 5/21/2025 6:11 PM, Richard Heathfield wrote:
Turing proved that what you're asking is impossible.That is not what he proved.
Then you'll be able to write a universal termination analyser that can >>>>> correctly report for any program and any input whether it halts. Good >>>>> luck with that.
Not necessarily.
Of course not. But I'm just reflecting. He seemed to think that my
inability to write the kind of program Turing envisaged (an inability
that I readily concede) is evidence for his argument. Well, what's
sauce for the goose is sauce for the gander.
Even if olcott had refuted the proofs of the
insolvability of the Halting Problem -- or even if he had proved
that a universal halt decider is possible
And we both know what we both think of that idea.
-- that doesn't imply
that he or anyone else would be able to write one.
Indeed.
I've never been entirely clear on what olcott is claiming.
Nor I. Mike Terry seems to have a pretty good handle on it, but no
matter how clearly he explains it to me my eyes glaze over and I
start to snore.
Hey, it's the way I tell 'em!
Here's what the tabloids might have said about it, if it had made the
front pages when the story broke:
COMPUTER BOFFIN IS TURING IN HIS GRAVE!
An Internet crank claims to have refuted Linz HP proof by creating a
Halt Decider that CORRECTLY decides its own "impossible input"!
The computing world is underwhelmed.
Better? (Appologies for the headline, it's the best I could come up
with.)
Mike.
There is a key detail about ALL of these proofs
that no one has paid attention to for 90 years.
It is impossible to define *AN INPUT* to HHH that
does the opposite of whatever value that HHH returns.
int main()
{
DD; // HHH cannot report on the behavior of its caller
} // *That is just not the way that computations work*
It is the same thing with the Linz proof.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
embedded_H cannot report on the behavior of
the computation that itself is contained within.
*That is just NOT THE WAY that computations work*
On 5/23/2025 2:09 AM, Mikko wrote:
On 2025-05-23 02:47:40 +0000, olcott said:
On 5/22/2025 8:24 PM, Mike Terry wrote:
On 22/05/2025 06:41, Richard Heathfield wrote:
On 22/05/2025 06:23, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 22/05/2025 00:14, olcott wrote:[...]
On 5/21/2025 6:11 PM, Richard Heathfield wrote:
Turing proved that what you're asking is impossible.That is not what he proved.
Then you'll be able to write a universal termination analyser
that can
correctly report for any program and any input whether it halts. >>>>>>> Good
luck with that.
Not necessarily.
Of course not. But I'm just reflecting. He seemed to think that my
inability to write the kind of program Turing envisaged (an
inability that I readily concede) is evidence for his argument.
Well, what's sauce for the goose is sauce for the gander.
Even if olcott had refuted the proofs of the
insolvability of the Halting Problem -- or even if he had proved
that a universal halt decider is possible
And we both know what we both think of that idea.
-- that doesn't imply
that he or anyone else would be able to write one.
Indeed.
I've never been entirely clear on what olcott is claiming.
Nor I. Mike Terry seems to have a pretty good handle on it, but no
matter how clearly he explains it to me my eyes glaze over and I
start to snore.
Hey, it's the way I tell 'em!
Here's what the tabloids might have said about it, if it had made
the front pages when the story broke:
COMPUTER BOFFIN IS TURING IN HIS GRAVE!
An Internet crank claims to have refuted Linz HP proof by creating a >>>> Halt Decider that CORRECTLY decides its own "impossible input"!
The computing world is underwhelmed.
Better? (Appologies for the headline, it's the best I could come up
with.)
Mike.
There is a key detail about ALL of these proofs
that no one has paid attention to for 90 years.
It is impossible to define *AN INPUT* to HHH that
does the opposite of whatever value that HHH returns.
That is a key detail about HHH. Your HHH is not a part of those proofs.
All of the proofs work this same way.
It is merely much easier to see in a fully defined
and fully operational language such as C/x86.
For every Turing machine presented as a halting decider it is possible
to construct a computation that that Turing machine cannot decide
correctly. If that computation cannot be presented as an input to HHH
then HHH is not a halting decider.
int main()
{
DD(); // Try to show how HHH called by DD can report
} // on the behavior of its caller.
HHH is not (and is not supposed to be) a halt decider for
its caller. That is just not the way that computations work.
On 5/23/2025 2:14 AM, Mikko wrote:
On 2025-05-23 03:31:15 +0000, olcott said:
On 5/22/2025 10:23 PM, wij wrote:
On Thu, 2025-05-22 at 21:47 -0500, olcott wrote:
[cut]
Q: How do computations actually work?
A: Computation is merely step-by-step algorithm.
Nothing says it has to be TM.
Do the exercises in textbooks first before any claim of it.
int main()
{
DD(); // by what steps can the HHH that DD calls
} // report on the behavior its caller?
If we don't insist that the report be correct:
1. guess
2. tell what was guessed
This does not work because all computable functions
that implement termination analyzers must compute
the mapping from their input finite string according
to the behavior that it specifies. In my concrete
examples DDD must be simulated by HHH according to the
rules of the x86 language.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
DDD specifies that it will continue to call HHH
until HHH sees the repeating pattern and aborts
its simulation.
On 5/23/2025 11:16 AM, Richard Damon wrote:
On 5/23/25 12:10 PM, olcott wrote:
On 5/23/2025 2:14 AM, Mikko wrote:
On 2025-05-23 03:31:15 +0000, olcott said:
On 5/22/2025 10:23 PM, wij wrote:
On Thu, 2025-05-22 at 21:47 -0500, olcott wrote:
[cut]
Q: How do computations actually work?
A: Computation is merely step-by-step algorithm.
Nothing says it has to be TM.
Do the exercises in textbooks first before any claim of it.
int main()
{
DD(); // by what steps can the HHH that DD calls
} // report on the behavior its caller?
If we don't insist that the report be correct:
1. guess
2. tell what was guessed
This does not work because all computable functions
that implement termination analyzers must compute
the mapping from their input finite string according
to the behavior that it specifies. In my concrete
examples DDD must be simulated by HHH according to the
rules of the x86 language.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
DDD specifies that it will continue to call HHH
until HHH sees the repeating pattern and aborts
its simulation.
Yes, they must compute the mapping, but the rules don't say HOW.
*They never bothered to say HOW until NOW*
The ultimate definition of a correct simulation
is a simulation according to the definition of
the simulation language.
One is not free to interpret "push ebp" as "jmp 00002183".
On 5/23/2025 1:03 PM, Fred. Zwarts wrote:
Op 23.mei.2025 om 19:00 schreef olcott:
On 5/23/2025 11:16 AM, Richard Damon wrote:
On 5/23/25 12:10 PM, olcott wrote:
On 5/23/2025 2:14 AM, Mikko wrote:
On 2025-05-23 03:31:15 +0000, olcott said:
On 5/22/2025 10:23 PM, wij wrote:
On Thu, 2025-05-22 at 21:47 -0500, olcott wrote:
[cut]
Q: How do computations actually work?
A: Computation is merely step-by-step algorithm.
Nothing says it has to be TM.
Do the exercises in textbooks first before any claim of it.
int main()
{
DD(); // by what steps can the HHH that DD calls
} // report on the behavior its caller?
If we don't insist that the report be correct:
1. guess
2. tell what was guessed
This does not work because all computable functions
that implement termination analyzers must compute
the mapping from their input finite string according
to the behavior that it specifies. In my concrete
examples DDD must be simulated by HHH according to the
rules of the x86 language.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
DDD specifies that it will continue to call HHH
until HHH sees the repeating pattern and aborts
its simulation.
Yes, they must compute the mapping, but the rules don't say HOW.
*They never bothered to say HOW until NOW*
The ultimate definition of a correct simulation
is a simulation according to the definition of
the simulation language.
One is not free to interpret "push ebp" as "jmp 00002183".
And one is not free to halt the simulation and ignore the halting
behaviour specified in the remainder of the input, because it is
against the rules of the simulation language.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Show me how DDD correctly simulated by HHH
reaches its own "ret" instruction.
You won't do this because you know that you
are a damned liar.
On 5/23/2025 11:16 AM, Richard Damon wrote:
On 5/23/25 12:10 PM, olcott wrote:
On 5/23/2025 2:14 AM, Mikko wrote:
On 2025-05-23 03:31:15 +0000, olcott said:
On 5/22/2025 10:23 PM, wij wrote:
On Thu, 2025-05-22 at 21:47 -0500, olcott wrote:
[cut]
Q: How do computations actually work?
A: Computation is merely step-by-step algorithm.
Nothing says it has to be TM.
Do the exercises in textbooks first before any claim of it.
int main()
{
DD(); // by what steps can the HHH that DD calls
} // report on the behavior its caller?
If we don't insist that the report be correct:
1. guess
2. tell what was guessed
This does not work because all computable functions
that implement termination analyzers must compute
the mapping from their input finite string according
to the behavior that it specifies. In my concrete
examples DDD must be simulated by HHH according to the
rules of the x86 language.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
DDD specifies that it will continue to call HHH
until HHH sees the repeating pattern and aborts
its simulation.
Yes, they must compute the mapping, but the rules don't say HOW.
*They never bothered to say HOW until NOW*
The ultimate definition of a correct simulation
is a simulation according to the definition of
the simulation language.
One is not free to interpret "push ebp" as "jmp 00002183".
On 5/23/2025 2:14 AM, Mikko wrote:
On 2025-05-23 03:31:15 +0000, olcott said:
On 5/22/2025 10:23 PM, wij wrote:
On Thu, 2025-05-22 at 21:47 -0500, olcott wrote:
[cut]
Q: How do computations actually work?
A: Computation is merely step-by-step algorithm.
Nothing says it has to be TM.
Do the exercises in textbooks first before any claim of it.
int main()
{
DD(); // by what steps can the HHH that DD calls
} // report on the behavior its caller?
If we don't insist that the report be correct:
1. guess
2. tell what was guessed
This does not work because all computable functions
that implement termination analyzers must compute
the mapping from their input finite string according
to the behavior that it specifies.
How do computations actually work?
On 5/23/2025 2:09 AM, Mikko wrote:
On 2025-05-23 02:47:40 +0000, olcott said:
On 5/22/2025 8:24 PM, Mike Terry wrote:
On 22/05/2025 06:41, Richard Heathfield wrote:
On 22/05/2025 06:23, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 22/05/2025 00:14, olcott wrote:[...]
On 5/21/2025 6:11 PM, Richard Heathfield wrote:
Turing proved that what you're asking is impossible.That is not what he proved.
Then you'll be able to write a universal termination analyser that can >>>>>>> correctly report for any program and any input whether it halts. Good >>>>>>> luck with that.
Not necessarily.
Of course not. But I'm just reflecting. He seemed to think that my
inability to write the kind of program Turing envisaged (an inability >>>>> that I readily concede) is evidence for his argument. Well, what's
sauce for the goose is sauce for the gander.
Even if olcott had refuted the proofs of the
insolvability of the Halting Problem -- or even if he had proved
that a universal halt decider is possible
And we both know what we both think of that idea.
-- that doesn't imply
that he or anyone else would be able to write one.
Indeed.
I've never been entirely clear on what olcott is claiming.
Nor I. Mike Terry seems to have a pretty good handle on it, but no
matter how clearly he explains it to me my eyes glaze over and I start >>>>> to snore.
Hey, it's the way I tell 'em!
Here's what the tabloids might have said about it, if it had made the
front pages when the story broke:
COMPUTER BOFFIN IS TURING IN HIS GRAVE!
An Internet crank claims to have refuted Linz HP proof by creating a >>>> Halt Decider that CORRECTLY decides its own "impossible input"!
The computing world is underwhelmed.
Better? (Appologies for the headline, it's the best I could come up with.)
Mike.
There is a key detail about ALL of these proofs
that no one has paid attention to for 90 years.
It is impossible to define *AN INPUT* to HHH that
does the opposite of whatever value that HHH returns.
That is a key detail about HHH. Your HHH is not a part of those proofs.
All of the proofs work this same way.
On 5/24/2025 2:39 AM, Mikko wrote:
On 2025-05-23 16:10:19 +0000, olcott said:
On 5/23/2025 2:14 AM, Mikko wrote:
On 2025-05-23 03:31:15 +0000, olcott said:
On 5/22/2025 10:23 PM, wij wrote:
On Thu, 2025-05-22 at 21:47 -0500, olcott wrote:
[cut]
Q: How do computations actually work?
A: Computation is merely step-by-step algorithm.
Nothing says it has to be TM.
Do the exercises in textbooks first before any claim of it.
int main()
{
DD(); // by what steps can the HHH that DD calls
} // report on the behavior its caller?
If we don't insist that the report be correct:
1. guess
2. tell what was guessed
This does not work because all computable functions
that implement termination analyzers must compute
the mapping from their input finite string according
to the behavior that it specifies.
Wrong. There is no need to compute "the" mapping if a the report
needs not be correct. Some other mapping is enough to produce
some report.
int sum(int x, int y) { return 5; }
Does not compute any function because it ignores its inputs.
On 5/24/2025 2:54 AM, Mikko wrote:
On 2025-05-23 16:04:49 +0000, olcott said:
On 5/23/2025 2:09 AM, Mikko wrote:
On 2025-05-23 02:47:40 +0000, olcott said:All of the proofs work this same way.
On 5/22/2025 8:24 PM, Mike Terry wrote:
On 22/05/2025 06:41, Richard Heathfield wrote:
On 22/05/2025 06:23, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 22/05/2025 00:14, olcott wrote:[...]
On 5/21/2025 6:11 PM, Richard Heathfield wrote:
Turing proved that what you're asking is impossible.That is not what he proved.
Then you'll be able to write a universal termination analyser >>>>>>>>> that can
correctly report for any program and any input whether it
halts. Good
luck with that.
Not necessarily.
Of course not. But I'm just reflecting. He seemed to think that
my inability to write the kind of program Turing envisaged (an
inability that I readily concede) is evidence for his argument.
Well, what's sauce for the goose is sauce for the gander.
Even if olcott had refuted the proofs of the
insolvability of the Halting Problem -- or even if he had proved >>>>>>>> that a universal halt decider is possible
And we both know what we both think of that idea.
-- that doesn't imply
that he or anyone else would be able to write one.
Indeed.
I've never been entirely clear on what olcott is claiming.
Nor I. Mike Terry seems to have a pretty good handle on it, but
no matter how clearly he explains it to me my eyes glaze over and >>>>>>> I start to snore.
Hey, it's the way I tell 'em!
Here's what the tabloids might have said about it, if it had made
the front pages when the story broke:
COMPUTER BOFFIN IS TURING IN HIS GRAVE!
An Internet crank claims to have refuted Linz HP proof by
creating a
Halt Decider that CORRECTLY decides its own "impossible input"! >>>>>> The computing world is underwhelmed.
Better? (Appologies for the headline, it's the best I could come >>>>>> up with.)
Mike.
There is a key detail about ALL of these proofs
that no one has paid attention to for 90 years.
It is impossible to define *AN INPUT* to HHH that
does the opposite of whatever value that HHH returns.
That is a key detail about HHH. Your HHH is not a part of those proofs. >>>
No, they don't. Some proofs derive the same conclusion with an
essentially
different approach.
However, in spite of the differences, they do share a common fieature:
your HHH is not a part of any of the proofs.
All of the conventional proofs of the HP assume that
there is an *input D* that can actually do the opposite
of whatever value that HHH returns. For 90 years people
got totally confused about what an input is and what
it is not.
int main()
{
DD(); // This DD is not the input to the HHH that DD calls.
} // It has always had a different execution trace than
// DD simulated by HHH according to the rules of the
// x86 language.
On 5/24/2025 2:47 AM, Mikko wrote:
On 2025-05-23 02:47:40 +0000, olcott changed the subject to
How do computations actually work?
Each computation works differently. It does not matter how it works as
long as there are instructions that fully specify how that computation
shall be performed.
All termination analyzers are required to report on the
behavior that their input finite string specifies.
int main()
{
DD(); // the HHH that DD calls cannot report on the
} // behavior of its caller. That is just not
// the way that these things work.
int sum(int x int y) { return x + y; }
computes the sum of its inputs according to the rules of arithmetic.
Does not compute any function
int sum(int x int y) { return 5; }
Does not compute the function of sum correctly.
int sum(int x int y) { x + x; }
On 5/24/2025 10:15 AM, dbush wrote:
On 5/24/2025 11:13 AM, olcott wrote:
On 5/24/2025 2:39 AM, Mikko wrote:
On 2025-05-23 16:10:19 +0000, olcott said:
On 5/23/2025 2:14 AM, Mikko wrote:
On 2025-05-23 03:31:15 +0000, olcott said:
On 5/22/2025 10:23 PM, wij wrote:
On Thu, 2025-05-22 at 21:47 -0500, olcott wrote:
[cut]
Q: How do computations actually work?
A: Computation is merely step-by-step algorithm.
Nothing says it has to be TM.
Do the exercises in textbooks first before any claim of it.
int main()
{
DD(); // by what steps can the HHH that DD calls
} // report on the behavior its caller?
If we don't insist that the report be correct:
1. guess
2. tell what was guessed
This does not work because all computable functions
that implement termination analyzers must compute
the mapping from their input finite string according
to the behavior that it specifies.
Wrong. There is no need to compute "the" mapping if a the report
needs not be correct. Some other mapping is enough to produce
some report.
int sum(int x, int y) { return 5; }
Does not compute any function because it ignores its inputs.
Sure it does. It computes this function:
For all integers X and Y:
(X,Y) maps to 5
The only requirements for mapping is a function is that inputs
correspond to outputs as per the given mapping, and the mathematical
function above is mapped by the above C function "sum".
OK
int main()
{
DD(); // How does the HHH that DD calls report on the
} // actual behavior of its actual caller?
On 5/24/2025 2:39 AM, Mikko wrote:
On 2025-05-23 16:10:19 +0000, olcott said:
On 5/23/2025 2:14 AM, Mikko wrote:
On 2025-05-23 03:31:15 +0000, olcott said:
On 5/22/2025 10:23 PM, wij wrote:
On Thu, 2025-05-22 at 21:47 -0500, olcott wrote:
[cut]
Q: How do computations actually work?
A: Computation is merely step-by-step algorithm.
Nothing says it has to be TM.
Do the exercises in textbooks first before any claim of it.
int main()
{
DD(); // by what steps can the HHH that DD calls
} // report on the behavior its caller?
If we don't insist that the report be correct:
1. guess
2. tell what was guessed
This does not work because all computable functions
that implement termination analyzers must compute
the mapping from their input finite string according
to the behavior that it specifies.
Wrong. There is no need to compute "the" mapping if a the report
needs not be correct. Some other mapping is enough to produce
some report.
int sum(int x, int y) { return 5; }
Does not compute any function because it ignores its inputs.
On 5/24/2025 2:54 AM, Mikko wrote:
On 2025-05-23 16:04:49 +0000, olcott said:
On 5/23/2025 2:09 AM, Mikko wrote:
On 2025-05-23 02:47:40 +0000, olcott said:All of the proofs work this same way.
On 5/22/2025 8:24 PM, Mike Terry wrote:
On 22/05/2025 06:41, Richard Heathfield wrote:
On 22/05/2025 06:23, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 22/05/2025 00:14, olcott wrote:[...]
On 5/21/2025 6:11 PM, Richard Heathfield wrote:
Turing proved that what you're asking is impossible.That is not what he proved.
Then you'll be able to write a universal termination analyser that can
correctly report for any program and any input whether it halts. Good >>>>>>>>> luck with that.
Not necessarily.
Of course not. But I'm just reflecting. He seemed to think that my >>>>>>> inability to write the kind of program Turing envisaged (an inability >>>>>>> that I readily concede) is evidence for his argument. Well, what's >>>>>>> sauce for the goose is sauce for the gander.
Even if olcott had refuted the proofs of the
insolvability of the Halting Problem -- or even if he had proved >>>>>>>> that a universal halt decider is possible
And we both know what we both think of that idea.
-- that doesn't imply
that he or anyone else would be able to write one.
Indeed.
I've never been entirely clear on what olcott is claiming.
Nor I. Mike Terry seems to have a pretty good handle on it, but no >>>>>>> matter how clearly he explains it to me my eyes glaze over and I start >>>>>>> to snore.
Hey, it's the way I tell 'em!
Here's what the tabloids might have said about it, if it had made the >>>>>> front pages when the story broke:
COMPUTER BOFFIN IS TURING IN HIS GRAVE!
An Internet crank claims to have refuted Linz HP proof by creating a >>>>>> Halt Decider that CORRECTLY decides its own "impossible input"! >>>>>> The computing world is underwhelmed.
Better? (Appologies for the headline, it's the best I could come up with.)
Mike.
There is a key detail about ALL of these proofs
that no one has paid attention to for 90 years.
It is impossible to define *AN INPUT* to HHH that
does the opposite of whatever value that HHH returns.
That is a key detail about HHH. Your HHH is not a part of those proofs. >>>
No, they don't. Some proofs derive the same conclusion with an essentially >> different approach.
However, in spite of the differences, they do share a common fieature:
your HHH is not a part of any of the proofs.
All of the conventional proofs of the HP assume that
there is an *input D* that can actually do the opposite
of whatever value that HHH returns.
On 5/24/2025 2:47 AM, Mikko wrote:
On 2025-05-23 02:47:40 +0000, olcott changed the subject to
How do computations actually work?
Each computation works differently. It does not matter how it works as
long as there are instructions that fully specify how that computation
shall be performed.
All termination analyzers are required to report on the
behavior that their input finite string specifies.
On 2025-05-24 15:18:57 +0000, olcott said:
All termination analyzers are required to report on the
behavior that their input finite string specifies.
To report correctly. Though the input string to a termination
analyzer usially is incomlete: the input string usually
specifies different behavours depending on the input that is
not shown to the termination analyzer, and the analyzer's
report must cover all of them.
To report correctly. Though the input string to a termination
analyzer usially is incomlete: the input string usually
specifies different behavours depending on the input that is
not shown to the termination analyzer, and the analyzer's
report must cover all of them.
On 25/05/2025 10:14, Mikko wrote:
On 2025-05-24 15:18:57 +0000, olcott said:
<snip>
All termination analyzers are required to report on the
behavior that their input finite string specifies.
To report correctly. Though the input string to a termination analyzer
usially is incomlete: the input string usually
specifies different behavours depending on the input that is
not shown to the termination analyzer, and the analyzer's
report must cover all of them.
I think 'input string' is ambiguous here.
It would be clearer if people used 'program string' if they mean the
program whose halting behaviour is being investigated and reserved
'input string' for when they mean the data - that is:
The analyser must determine whether the program string would terminate
if applied to the input string.
Clearer still would be to drop 'string' and set up a couple of
unambiguous aliases:
The analyser must determine whether program P would terminate if applied
to input tape T.
In the above, requoted here:
To report correctly. Though the input string to a termination
analyzer usially is incomlete: the input string usually
specifies different behavours depending on the input that is
not shown to the termination analyzer, and the analyzer's
report must cover all of them.
I can't decide which 'input string' means P and which means T.
"Program Deciders", the input to the decider is a single string
which represents both the program and its input string. In this
case both are generally given name.
On 5/25/2025 4:09 AM, Mikko wrote:
On 2025-05-24 15:25:21 +0000, olcott said:
On 5/24/2025 2:54 AM, Mikko wrote:
On 2025-05-23 16:04:49 +0000, olcott said:
On 5/23/2025 2:09 AM, Mikko wrote:
On 2025-05-23 02:47:40 +0000, olcott said:
On 5/22/2025 8:24 PM, Mike Terry wrote:
On 22/05/2025 06:41, Richard Heathfield wrote:
On 22/05/2025 06:23, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 22/05/2025 00:14, olcott wrote:[...]
On 5/21/2025 6:11 PM, Richard Heathfield wrote:
Turing proved that what you're asking is impossible. >>>>>>>>>>>>>That is not what he proved.
Then you'll be able to write a universal termination analyser >>>>>>>>>>> that can
correctly report for any program and any input whether it >>>>>>>>>>> halts. Good
luck with that.
Not necessarily.
Of course not. But I'm just reflecting. He seemed to think that >>>>>>>>> my inability to write the kind of program Turing envisaged (an >>>>>>>>> inability that I readily concede) is evidence for his argument. >>>>>>>>> Well, what's sauce for the goose is sauce for the gander.
Even if olcott had refuted the proofs of the
insolvability of the Halting Problem -- or even if he had proved >>>>>>>>>> that a universal halt decider is possible
And we both know what we both think of that idea.
-- that doesn't imply
that he or anyone else would be able to write one.
Indeed.
I've never been entirely clear on what olcott is claiming.
Nor I. Mike Terry seems to have a pretty good handle on it, but >>>>>>>>> no matter how clearly he explains it to me my eyes glaze over >>>>>>>>> and I start to snore.
Hey, it's the way I tell 'em!
Here's what the tabloids might have said about it, if it had
made the front pages when the story broke:
COMPUTER BOFFIN IS TURING IN HIS GRAVE!
An Internet crank claims to have refuted Linz HP proof by
creating a
Halt Decider that CORRECTLY decides its own "impossible input"! >>>>>>>> The computing world is underwhelmed.
Better? (Appologies for the headline, it's the best I could
come up with.)
Mike.
There is a key detail about ALL of these proofs
that no one has paid attention to for 90 years.
It is impossible to define *AN INPUT* to HHH that
does the opposite of whatever value that HHH returns.
That is a key detail about HHH. Your HHH is not a part of those
proofs.
All of the proofs work this same way.
No, they don't. Some proofs derive the same conclusion with an
essentially
different approach.
However, in spite of the differences, they do share a common fieature: >>>> your HHH is not a part of any of the proofs.
All of the conventional proofs of the HP assume that
there is an *input D* that can actually do the opposite
of whatever value that HHH returns.
Depends on what you mean by "conventional". If you merely mean proofs
that apply ordinary logic then there are proofs with a different
strategy. If you mean only proofs that use the same strategy that
Turing used then you are closer to the truth. But there is no assumption
about the exstence of such D. Its existence is proven.
In seems that way until you pay much closer attention.
int main()
{
DDD(); // The HHH that DDD calls cannot report on the
} // behavior of its caller because it cannot see
// is caller.
Even if HHH could see and report on the behavior of
its caller because its caller is not its input this
too is no good.
On 25/05/2025 12:44, Richard Damon wrote:
<snip>
; With Halt Deciders, and other
"Program Deciders", the input to the decider is a single string which
represents both the program and its input string. In this case both
are generally given name.
So you put the program and the input on the same tape. Sounds like a
somewhat profligate use of tape, but okay, it does resolve the ambiguity.
On 5/25/2025 4:09 AM, Mikko wrote:
On 2025-05-24 15:25:21 +0000, olcott said:
On 5/24/2025 2:54 AM, Mikko wrote:
On 2025-05-23 16:04:49 +0000, olcott said:
On 5/23/2025 2:09 AM, Mikko wrote:
On 2025-05-23 02:47:40 +0000, olcott said:
On 5/22/2025 8:24 PM, Mike Terry wrote:
On 22/05/2025 06:41, Richard Heathfield wrote:
On 22/05/2025 06:23, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 22/05/2025 00:14, olcott wrote:[...]
On 5/21/2025 6:11 PM, Richard Heathfield wrote:
Turing proved that what you're asking is impossible. >>>>>>>>>>>>>That is not what he proved.
Then you'll be able to write a universal termination analyser >>>>>>>>>>> that can
correctly report for any program and any input whether it >>>>>>>>>>> halts. Good
luck with that.
Not necessarily.
Of course not. But I'm just reflecting. He seemed to think that >>>>>>>>> my inability to write the kind of program Turing envisaged (an >>>>>>>>> inability that I readily concede) is evidence for his argument. >>>>>>>>> Well, what's sauce for the goose is sauce for the gander.
Even if olcott had refuted the proofs of the
insolvability of the Halting Problem -- or even if he had proved >>>>>>>>>> that a universal halt decider is possible
And we both know what we both think of that idea.
-- that doesn't imply
that he or anyone else would be able to write one.
Indeed.
I've never been entirely clear on what olcott is claiming.
Nor I. Mike Terry seems to have a pretty good handle on it, but >>>>>>>>> no matter how clearly he explains it to me my eyes glaze over >>>>>>>>> and I start to snore.
Hey, it's the way I tell 'em!
Here's what the tabloids might have said about it, if it had
made the front pages when the story broke:
COMPUTER BOFFIN IS TURING IN HIS GRAVE!
An Internet crank claims to have refuted Linz HP proof by
creating a
Halt Decider that CORRECTLY decides its own "impossible input"! >>>>>>>> The computing world is underwhelmed.
Better? (Appologies for the headline, it's the best I could
come up with.)
Mike.
There is a key detail about ALL of these proofs
that no one has paid attention to for 90 years.
It is impossible to define *AN INPUT* to HHH that
does the opposite of whatever value that HHH returns.
That is a key detail about HHH. Your HHH is not a part of those
proofs.
All of the proofs work this same way.
No, they don't. Some proofs derive the same conclusion with an
essentially
different approach.
However, in spite of the differences, they do share a common fieature: >>>> your HHH is not a part of any of the proofs.
All of the conventional proofs of the HP assume that
there is an *input D* that can actually do the opposite
of whatever value that HHH returns.
Depends on what you mean by "conventional". If you merely mean proofs
that apply ordinary logic then there are proofs with a different
strategy. If you mean only proofs that use the same strategy that
Turing used then you are closer to the truth. But there is no assumption
about the exstence of such D. Its existence is proven.
In seems that way until you pay much closer attention.
int main()
{
DDD(); // The HHH that DDD calls cannot report on the
} // behavior of its caller because it cannot see
// is caller.
Even if HHH could see and report on the behavior of
its caller because its caller is not its input this
too is no good.
Most people miss this key point.
They think that its caller, and its input are exactly
the same thing. When you see that encoded in C then
this assumption is proven to be ridiculously false.
On 5/25/2025 4:14 AM, Mikko wrote:
On 2025-05-24 15:18:57 +0000, olcott said:
On 5/24/2025 2:47 AM, Mikko wrote:
On 2025-05-23 02:47:40 +0000, olcott changed the subject to
How do computations actually work?
Each computation works differently. It does not matter how it works as >>>> long as there are instructions that fully specify how that computation >>>> shall be performed.
All termination analyzers are required to report on the
behavior that their input finite string specifies.
To report correctly. Though the input string to a termination analyzer
usially is incomlete: the input string usually specifies different
behavours depending on the input that is not shown to the termination
analyzer, and the analyzer's report must cover all of them.
A partial termination analyzer may fail to report but is not allowed
to report incorrectly.
void DDD()
{
HHH(DDD);
return;
}
DDD simulated by HHH cannot possibly reach its
"return" statement final halt state, only liars
will disagree.
On 5/25/2025 4:09 AM, Mikko wrote:
On 2025-05-24 15:25:21 +0000, olcott said:
On 5/24/2025 2:54 AM, Mikko wrote:
On 2025-05-23 16:04:49 +0000, olcott said:
On 5/23/2025 2:09 AM, Mikko wrote:
On 2025-05-23 02:47:40 +0000, olcott said:All of the proofs work this same way.
On 5/22/2025 8:24 PM, Mike Terry wrote:
On 22/05/2025 06:41, Richard Heathfield wrote:
On 22/05/2025 06:23, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 22/05/2025 00:14, olcott wrote:[...]
On 5/21/2025 6:11 PM, Richard Heathfield wrote:
Turing proved that what you're asking is impossible. >>>>>>>>>>>>>That is not what he proved.
Then you'll be able to write a universal termination analyser that can
correctly report for any program and any input whether it halts. Good
luck with that.
Not necessarily.
Of course not. But I'm just reflecting. He seemed to think that my >>>>>>>>> inability to write the kind of program Turing envisaged (an inability >>>>>>>>> that I readily concede) is evidence for his argument. Well, what's >>>>>>>>> sauce for the goose is sauce for the gander.
Even if olcott had refuted the proofs of the
insolvability of the Halting Problem -- or even if he had proved >>>>>>>>>> that a universal halt decider is possible
And we both know what we both think of that idea.
-- that doesn't imply
that he or anyone else would be able to write one.
Indeed.
I've never been entirely clear on what olcott is claiming.
Nor I. Mike Terry seems to have a pretty good handle on it, but no >>>>>>>>> matter how clearly he explains it to me my eyes glaze over and I start
to snore.
Hey, it's the way I tell 'em!
Here's what the tabloids might have said about it, if it had made the >>>>>>>> front pages when the story broke:
COMPUTER BOFFIN IS TURING IN HIS GRAVE!
An Internet crank claims to have refuted Linz HP proof by creating a
Halt Decider that CORRECTLY decides its own "impossible input"! >>>>>>>> The computing world is underwhelmed.
Better? (Appologies for the headline, it's the best I could come up with.)
Mike.
There is a key detail about ALL of these proofs
that no one has paid attention to for 90 years.
It is impossible to define *AN INPUT* to HHH that
does the opposite of whatever value that HHH returns.
That is a key detail about HHH. Your HHH is not a part of those proofs. >>>>>
No, they don't. Some proofs derive the same conclusion with an essentially >>>> different approach.
However, in spite of the differences, they do share a common fieature: >>>> your HHH is not a part of any of the proofs.
All of the conventional proofs of the HP assume that
there is an *input D* that can actually do the opposite
of whatever value that HHH returns.
Depends on what you mean by "conventional". If you merely mean proofs
that apply ordinary logic then there are proofs with a different
strategy. If you mean only proofs that use the same strategy that
Turing used then you are closer to the truth. But there is no assumption
about the exstence of such D. Its existence is proven.
In seems that way until you pay much closer attention.
int main()
{
DDD(); // The HHH that DDD calls cannot report on the
} // behavior of its caller because it cannot see
// is caller.
On 5/25/2025 4:14 AM, Mikko wrote:
On 2025-05-24 15:18:57 +0000, olcott said:
On 5/24/2025 2:47 AM, Mikko wrote:
On 2025-05-23 02:47:40 +0000, olcott changed the subject to
How do computations actually work?
Each computation works differently. It does not matter how it works as >>>> long as there are instructions that fully specify how that computation >>>> shall be performed.
All termination analyzers are required to report on the
behavior that their input finite string specifies.
To report correctly. Though the input string to a termination analyzer
usially is incomlete: the input string usually specifies different
behavours depending on the input that is not shown to the termination
analyzer, and the analyzer's report must cover all of them.
A partial termination analyzer may fail to report but is not allowed
to report incorrectly.
void DDD()
{
HHH(DDD);
return;
}
DDD simulated by HHH cannot possibly reach its
"return" statement final halt state, only liars
will disagree.
On 5/26/2025 3:38 AM, Mikko wrote:
On 2025-05-25 14:50:58 +0000, olcott said:
On 5/25/2025 4:09 AM, Mikko wrote:
On 2025-05-24 15:25:21 +0000, olcott said:
On 5/24/2025 2:54 AM, Mikko wrote:
On 2025-05-23 16:04:49 +0000, olcott said:
On 5/23/2025 2:09 AM, Mikko wrote:
On 2025-05-23 02:47:40 +0000, olcott said:
On 5/22/2025 8:24 PM, Mike Terry wrote:
On 22/05/2025 06:41, Richard Heathfield wrote:
On 22/05/2025 06:23, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 22/05/2025 00:14, olcott wrote:[...]
On 5/21/2025 6:11 PM, Richard Heathfield wrote:
Turing proved that what you're asking is impossible. >>>>>>>>>>>>>>>That is not what he proved.
Then you'll be able to write a universal termination >>>>>>>>>>>>> analyser that can
correctly report for any program and any input whether it >>>>>>>>>>>>> halts. Good
luck with that.
Not necessarily.
Of course not. But I'm just reflecting. He seemed to think >>>>>>>>>>> that my inability to write the kind of program Turing
envisaged (an inability that I readily concede) is evidence >>>>>>>>>>> for his argument. Well, what's sauce for the goose is sauce >>>>>>>>>>> for the gander.
Even if olcott had refuted the proofs of the
insolvability of the Halting Problem -- or even if he had >>>>>>>>>>>> proved
that a universal halt decider is possible
And we both know what we both think of that idea.
-- that doesn't imply
that he or anyone else would be able to write one.
Indeed.
I've never been entirely clear on what olcott is claiming. >>>>>>>>>>>Nor I. Mike Terry seems to have a pretty good handle on it, >>>>>>>>>>> but no matter how clearly he explains it to me my eyes glaze >>>>>>>>>>> over and I start to snore.
Hey, it's the way I tell 'em!
Here's what the tabloids might have said about it, if it had >>>>>>>>>> made the front pages when the story broke:
COMPUTER BOFFIN IS TURING IN HIS GRAVE!
An Internet crank claims to have refuted Linz HP proof by >>>>>>>>>> creating a
Halt Decider that CORRECTLY decides its own "impossible input"! >>>>>>>>>> The computing world is underwhelmed.
Better? (Appologies for the headline, it's the best I could >>>>>>>>>> come up with.)
Mike.
There is a key detail about ALL of these proofs
that no one has paid attention to for 90 years.
It is impossible to define *AN INPUT* to HHH that
does the opposite of whatever value that HHH returns.
That is a key detail about HHH. Your HHH is not a part of those >>>>>>>> proofs.
All of the proofs work this same way.
No, they don't. Some proofs derive the same conclusion with an
essentially
different approach.
However, in spite of the differences, they do share a common
fieature:
your HHH is not a part of any of the proofs.
All of the conventional proofs of the HP assume that
there is an *input D* that can actually do the opposite
of whatever value that HHH returns.
Depends on what you mean by "conventional". If you merely mean proofs
that apply ordinary logic then there are proofs with a different
strategy. If you mean only proofs that use the same strategy that
Turing used then you are closer to the truth. But there is no
assumption
about the exstence of such D. Its existence is proven.
In seems that way until you pay much closer attention.
No, it seems that way when you pay enough attention.
int main()
{
DDD(); // The HHH that DDD calls cannot report on the
} // behavior of its caller because it cannot see
// is caller.
If HHH is correctly constructed it does see DDD and everything DDD
calls. Nothing else is relevant.
Try to show how HHH can see anything about its own caller
when HHH is not even allowed to look at its caller.
On 5/26/2025 11:05 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 17:50 schreef olcott:
On 5/26/2025 3:38 AM, Mikko wrote:
On 2025-05-25 14:50:58 +0000, olcott said:
On 5/25/2025 4:09 AM, Mikko wrote:
On 2025-05-24 15:25:21 +0000, olcott said:
On 5/24/2025 2:54 AM, Mikko wrote:
On 2025-05-23 16:04:49 +0000, olcott said:
On 5/23/2025 2:09 AM, Mikko wrote:
On 2025-05-23 02:47:40 +0000, olcott said:
On 5/22/2025 8:24 PM, Mike Terry wrote:
On 22/05/2025 06:41, Richard Heathfield wrote:
On 22/05/2025 06:23, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 22/05/2025 00:14, olcott wrote:[...]
On 5/21/2025 6:11 PM, Richard Heathfield wrote:
Turing proved that what you're asking is impossible. >>>>>>>>>>>>>>>>>That is not what he proved.
Then you'll be able to write a universal termination >>>>>>>>>>>>>>> analyser that can
correctly report for any program and any input whether it >>>>>>>>>>>>>>> halts. Good
luck with that.
Not necessarily.
Of course not. But I'm just reflecting. He seemed to think >>>>>>>>>>>>> that my inability to write the kind of program Turing >>>>>>>>>>>>> envisaged (an inability that I readily concede) is evidence >>>>>>>>>>>>> for his argument. Well, what's sauce for the goose is sauce >>>>>>>>>>>>> for the gander.
Even if olcott had refuted the proofs of the
insolvability of the Halting Problem -- or even if he had >>>>>>>>>>>>>> proved
that a universal halt decider is possible
And we both know what we both think of that idea.
-- that doesn't imply
that he or anyone else would be able to write one.
Indeed.
I've never been entirely clear on what olcott is claiming. >>>>>>>>>>>>>Nor I. Mike Terry seems to have a pretty good handle on it, >>>>>>>>>>>>> but no matter how clearly he explains it to me my eyes >>>>>>>>>>>>> glaze over and I start to snore.
Hey, it's the way I tell 'em!
Here's what the tabloids might have said about it, if it had >>>>>>>>>>>> made the front pages when the story broke:
COMPUTER BOFFIN IS TURING IN HIS GRAVE!
An Internet crank claims to have refuted Linz HP proof by >>>>>>>>>>>> creating a
Halt Decider that CORRECTLY decides its own "impossible >>>>>>>>>>>> input"!
The computing world is underwhelmed.
Better? (Appologies for the headline, it's the best I could >>>>>>>>>>>> come up with.)
Mike.
There is a key detail about ALL of these proofs
that no one has paid attention to for 90 years.
It is impossible to define *AN INPUT* to HHH that
does the opposite of whatever value that HHH returns.
That is a key detail about HHH. Your HHH is not a part of
those proofs.
All of the proofs work this same way.
No, they don't. Some proofs derive the same conclusion with an >>>>>>>> essentially
different approach.
However, in spite of the differences, they do share a common
fieature:
your HHH is not a part of any of the proofs.
All of the conventional proofs of the HP assume that
there is an *input D* that can actually do the opposite
of whatever value that HHH returns.
Depends on what you mean by "conventional". If you merely mean proofs >>>>>> that apply ordinary logic then there are proofs with a different
strategy. If you mean only proofs that use the same strategy that
Turing used then you are closer to the truth. But there is no
assumption
about the exstence of such D. Its existence is proven.
In seems that way until you pay much closer attention.
No, it seems that way when you pay enough attention.
int main()
{
DDD(); // The HHH that DDD calls cannot report on the
} // behavior of its caller because it cannot see
// is caller.
If HHH is correctly constructed it does see DDD and everything DDD
calls. Nothing else is relevant.
Try to show how HHH can see anything about its own caller
when HHH is not even allowed to look at its caller.
It is irrelevant whether DDD is the caller of HHH or not.
int main()
{
HHH(DDD);
return;
}
Now HHH is not called from HHH, but has the same input and it should
see that DDD includes the Halt7.c code, which aborts, so it should
see: a halting program.
In other words you fail to understand that
halting requires reaching a final halt state.
On 5/26/2025 3:38 AM, Mikko wrote:
On 2025-05-25 14:50:58 +0000, olcott said:
On 5/25/2025 4:09 AM, Mikko wrote:
On 2025-05-24 15:25:21 +0000, olcott said:
On 5/24/2025 2:54 AM, Mikko wrote:
On 2025-05-23 16:04:49 +0000, olcott said:
On 5/23/2025 2:09 AM, Mikko wrote:
On 2025-05-23 02:47:40 +0000, olcott said:
On 5/22/2025 8:24 PM, Mike Terry wrote:
On 22/05/2025 06:41, Richard Heathfield wrote:
On 22/05/2025 06:23, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 22/05/2025 00:14, olcott wrote:[...]
On 5/21/2025 6:11 PM, Richard Heathfield wrote:
Turing proved that what you're asking is impossible. >>>>>>>>>>>>>>>That is not what he proved.
Then you'll be able to write a universal termination >>>>>>>>>>>>> analyser that can
correctly report for any program and any input whether it >>>>>>>>>>>>> halts. Good
luck with that.
Not necessarily.
Of course not. But I'm just reflecting. He seemed to think >>>>>>>>>>> that my inability to write the kind of program Turing
envisaged (an inability that I readily concede) is evidence >>>>>>>>>>> for his argument. Well, what's sauce for the goose is sauce >>>>>>>>>>> for the gander.
Even if olcott had refuted the proofs of the
insolvability of the Halting Problem -- or even if he had >>>>>>>>>>>> proved
that a universal halt decider is possible
And we both know what we both think of that idea.
-- that doesn't imply
that he or anyone else would be able to write one.
Indeed.
I've never been entirely clear on what olcott is claiming. >>>>>>>>>>>Nor I. Mike Terry seems to have a pretty good handle on it, >>>>>>>>>>> but no matter how clearly he explains it to me my eyes glaze >>>>>>>>>>> over and I start to snore.
Hey, it's the way I tell 'em!
Here's what the tabloids might have said about it, if it had >>>>>>>>>> made the front pages when the story broke:
COMPUTER BOFFIN IS TURING IN HIS GRAVE!
An Internet crank claims to have refuted Linz HP proof by >>>>>>>>>> creating a
Halt Decider that CORRECTLY decides its own "impossible input"! >>>>>>>>>> The computing world is underwhelmed.
Better? (Appologies for the headline, it's the best I could >>>>>>>>>> come up with.)
Mike.
There is a key detail about ALL of these proofs
that no one has paid attention to for 90 years.
It is impossible to define *AN INPUT* to HHH that
does the opposite of whatever value that HHH returns.
That is a key detail about HHH. Your HHH is not a part of those >>>>>>>> proofs.
All of the proofs work this same way.
No, they don't. Some proofs derive the same conclusion with an
essentially
different approach.
However, in spite of the differences, they do share a common
fieature:
your HHH is not a part of any of the proofs.
All of the conventional proofs of the HP assume that
there is an *input D* that can actually do the opposite
of whatever value that HHH returns.
Depends on what you mean by "conventional". If you merely mean proofs
that apply ordinary logic then there are proofs with a different
strategy. If you mean only proofs that use the same strategy that
Turing used then you are closer to the truth. But there is no
assumption
about the exstence of such D. Its existence is proven.
In seems that way until you pay much closer attention.
No, it seems that way when you pay enough attention.
int main()
{
DDD(); // The HHH that DDD calls cannot report on the
} // behavior of its caller because it cannot see
// is caller.
If HHH is correctly constructed it does see DDD and everything DDD
calls. Nothing else is relevant.
Try to show how HHH can see anything about its own caller
when HHH is not even allowed to look at its caller.
On 5/26/2025 11:05 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 17:50 schreef olcott:
On 5/26/2025 3:38 AM, Mikko wrote:
On 2025-05-25 14:50:58 +0000, olcott said:
On 5/25/2025 4:09 AM, Mikko wrote:
On 2025-05-24 15:25:21 +0000, olcott said:
On 5/24/2025 2:54 AM, Mikko wrote:
On 2025-05-23 16:04:49 +0000, olcott said:
On 5/23/2025 2:09 AM, Mikko wrote:
On 2025-05-23 02:47:40 +0000, olcott said:
On 5/22/2025 8:24 PM, Mike Terry wrote:
On 22/05/2025 06:41, Richard Heathfield wrote:
On 22/05/2025 06:23, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 22/05/2025 00:14, olcott wrote:[...]
On 5/21/2025 6:11 PM, Richard Heathfield wrote:
Turing proved that what you're asking is impossible. >>>>>>>>>>>>>>>>>That is not what he proved.
Then you'll be able to write a universal termination >>>>>>>>>>>>>>> analyser that can
correctly report for any program and any input whether it >>>>>>>>>>>>>>> halts. Good
luck with that.
Not necessarily.
Of course not. But I'm just reflecting. He seemed to think >>>>>>>>>>>>> that my inability to write the kind of program Turing >>>>>>>>>>>>> envisaged (an inability that I readily concede) is evidence >>>>>>>>>>>>> for his argument. Well, what's sauce for the goose is sauce >>>>>>>>>>>>> for the gander.
Even if olcott had refuted the proofs of the
insolvability of the Halting Problem -- or even if he had >>>>>>>>>>>>>> proved
that a universal halt decider is possible
And we both know what we both think of that idea.
-- that doesn't imply
that he or anyone else would be able to write one.
Indeed.
I've never been entirely clear on what olcott is claiming. >>>>>>>>>>>>>Nor I. Mike Terry seems to have a pretty good handle on it, >>>>>>>>>>>>> but no matter how clearly he explains it to me my eyes >>>>>>>>>>>>> glaze over and I start to snore.
Hey, it's the way I tell 'em!
Here's what the tabloids might have said about it, if it had >>>>>>>>>>>> made the front pages when the story broke:
COMPUTER BOFFIN IS TURING IN HIS GRAVE!
An Internet crank claims to have refuted Linz HP proof by >>>>>>>>>>>> creating a
Halt Decider that CORRECTLY decides its own "impossible >>>>>>>>>>>> input"!
The computing world is underwhelmed.
Better? (Appologies for the headline, it's the best I could >>>>>>>>>>>> come up with.)
Mike.
There is a key detail about ALL of these proofs
that no one has paid attention to for 90 years.
It is impossible to define *AN INPUT* to HHH that
does the opposite of whatever value that HHH returns.
That is a key detail about HHH. Your HHH is not a part of
those proofs.
All of the proofs work this same way.
No, they don't. Some proofs derive the same conclusion with an >>>>>>>> essentially
different approach.
However, in spite of the differences, they do share a common
fieature:
your HHH is not a part of any of the proofs.
All of the conventional proofs of the HP assume that
there is an *input D* that can actually do the opposite
of whatever value that HHH returns.
Depends on what you mean by "conventional". If you merely mean proofs >>>>>> that apply ordinary logic then there are proofs with a different
strategy. If you mean only proofs that use the same strategy that
Turing used then you are closer to the truth. But there is no
assumption
about the exstence of such D. Its existence is proven.
In seems that way until you pay much closer attention.
No, it seems that way when you pay enough attention.
int main()
{
DDD(); // The HHH that DDD calls cannot report on the
} // behavior of its caller because it cannot see
// is caller.
If HHH is correctly constructed it does see DDD and everything DDD
calls. Nothing else is relevant.
Try to show how HHH can see anything about its own caller
when HHH is not even allowed to look at its caller.
It is irrelevant whether DDD is the caller of HHH or not.
int main()
{
HHH(DDD);
return;
}
Now HHH is not called from HHH, but has the same input and it should
see that DDD includes the Halt7.c code, which aborts, so it should
see: a halting program.
In other words you fail to understand that
halting requires reaching a final halt state.
On 5/25/2025 10:46 AM, Fred. Zwarts wrote:
Op 25.mei.2025 om 16:50 schreef olcott:
On 5/25/2025 4:09 AM, Mikko wrote:
On 2025-05-24 15:25:21 +0000, olcott said:
On 5/24/2025 2:54 AM, Mikko wrote:
On 2025-05-23 16:04:49 +0000, olcott said:
On 5/23/2025 2:09 AM, Mikko wrote:
On 2025-05-23 02:47:40 +0000, olcott said:
On 5/22/2025 8:24 PM, Mike Terry wrote:
On 22/05/2025 06:41, Richard Heathfield wrote:
On 22/05/2025 06:23, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 22/05/2025 00:14, olcott wrote:[...]
On 5/21/2025 6:11 PM, Richard Heathfield wrote:
Turing proved that what you're asking is impossible. >>>>>>>>>>>>>>>That is not what he proved.
Then you'll be able to write a universal termination analyser that can
correctly report for any program and any input whether it halts. Good
luck with that.
Not necessarily.
Of course not. But I'm just reflecting. He seemed to think that my >>>>>>>>>>> inability to write the kind of program Turing envisaged (an inability
that I readily concede) is evidence for his argument. Well, what's >>>>>>>>>>> sauce for the goose is sauce for the gander.
Even if olcott had refuted the proofs of the
insolvability of the Halting Problem -- or even if he had proved >>>>>>>>>>>> that a universal halt decider is possible
And we both know what we both think of that idea.
-- that doesn't imply
that he or anyone else would be able to write one.
Indeed.
I've never been entirely clear on what olcott is claiming. >>>>>>>>>>>Nor I. Mike Terry seems to have a pretty good handle on it, but no >>>>>>>>>>> matter how clearly he explains it to me my eyes glaze over and I start
to snore.
Hey, it's the way I tell 'em!
Here's what the tabloids might have said about it, if it had made the
front pages when the story broke:
COMPUTER BOFFIN IS TURING IN HIS GRAVE!
An Internet crank claims to have refuted Linz HP proof by creating a
Halt Decider that CORRECTLY decides its own "impossible input"! >>>>>>>>>> The computing world is underwhelmed.
Better? (Appologies for the headline, it's the best I could come up with.)
Mike.
There is a key detail about ALL of these proofs
that no one has paid attention to for 90 years.
It is impossible to define *AN INPUT* to HHH that
does the opposite of whatever value that HHH returns.
That is a key detail about HHH. Your HHH is not a part of those proofs.
All of the proofs work this same way.
No, they don't. Some proofs derive the same conclusion with an essentially
different approach.
However, in spite of the differences, they do share a common fieature: >>>>>> your HHH is not a part of any of the proofs.
All of the conventional proofs of the HP assume that
there is an *input D* that can actually do the opposite
of whatever value that HHH returns.
Depends on what you mean by "conventional". If you merely mean proofs
that apply ordinary logic then there are proofs with a different
strategy. If you mean only proofs that use the same strategy that
Turing used then you are closer to the truth. But there is no assumption >>>> about the exstence of such D. Its existence is proven.
In seems that way until you pay much closer attention.
int main()
{
DDD(); // The HHH that DDD calls cannot report on the
} // behavior of its caller because it cannot see
// is caller.
Even if HHH could see and report on the behavior of
its caller because its caller is not its input this
too is no good.
It seems that way to you, until you pay somewhat closer attention.
The HHH(DDD) must report on the behavior that its actual input
actually specified CANNOT BE VIOLATED.
On 5/26/2025 11:05 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 17:50 schreef olcott:
On 5/26/2025 3:38 AM, Mikko wrote:
On 2025-05-25 14:50:58 +0000, olcott said:
On 5/25/2025 4:09 AM, Mikko wrote:
On 2025-05-24 15:25:21 +0000, olcott said:
On 5/24/2025 2:54 AM, Mikko wrote:
On 2025-05-23 16:04:49 +0000, olcott said:
On 5/23/2025 2:09 AM, Mikko wrote:
On 2025-05-23 02:47:40 +0000, olcott said:
On 5/22/2025 8:24 PM, Mike Terry wrote:
On 22/05/2025 06:41, Richard Heathfield wrote:
On 22/05/2025 06:23, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 22/05/2025 00:14, olcott wrote:[...]
On 5/21/2025 6:11 PM, Richard Heathfield wrote:
Turing proved that what you're asking is impossible. >>>>>>>>>>>>>>>>>That is not what he proved.
Then you'll be able to write a universal termination analyser that can
correctly report for any program and any input whether it halts. Good
luck with that.
Not necessarily.
Of course not. But I'm just reflecting. He seemed to think that my
inability to write the kind of program Turing envisaged (an inability
that I readily concede) is evidence for his argument. Well, what's
sauce for the goose is sauce for the gander.
Even if olcott had refuted the proofs of the
insolvability of the Halting Problem -- or even if he had proved >>>>>>>>>>>>>> that a universal halt decider is possible
And we both know what we both think of that idea.
-- that doesn't imply
that he or anyone else would be able to write one.
Indeed.
I've never been entirely clear on what olcott is claiming. >>>>>>>>>>>>>Nor I. Mike Terry seems to have a pretty good handle on it, but no
matter how clearly he explains it to me my eyes glaze over and I start
to snore.
Hey, it's the way I tell 'em!
Here's what the tabloids might have said about it, if it had made the
front pages when the story broke:
COMPUTER BOFFIN IS TURING IN HIS GRAVE!
An Internet crank claims to have refuted Linz HP proof by creating a
Halt Decider that CORRECTLY decides its own "impossible input"! >>>>>>>>>>>> The computing world is underwhelmed.
Better? (Appologies for the headline, it's the best I could come up with.)
Mike.
There is a key detail about ALL of these proofs
that no one has paid attention to for 90 years.
It is impossible to define *AN INPUT* to HHH that
does the opposite of whatever value that HHH returns.
That is a key detail about HHH. Your HHH is not a part of those proofs.
All of the proofs work this same way.
No, they don't. Some proofs derive the same conclusion with an essentially
different approach.
However, in spite of the differences, they do share a common fieature: >>>>>>>> your HHH is not a part of any of the proofs.
All of the conventional proofs of the HP assume that
there is an *input D* that can actually do the opposite
of whatever value that HHH returns.
Depends on what you mean by "conventional". If you merely mean proofs >>>>>> that apply ordinary logic then there are proofs with a different
strategy. If you mean only proofs that use the same strategy that
Turing used then you are closer to the truth. But there is no assumption >>>>>> about the exstence of such D. Its existence is proven.
In seems that way until you pay much closer attention.
No, it seems that way when you pay enough attention.
int main()
{
DDD(); // The HHH that DDD calls cannot report on the
} // behavior of its caller because it cannot see
// is caller.
If HHH is correctly constructed it does see DDD and everything DDD
calls. Nothing else is relevant.
Try to show how HHH can see anything about its own caller
when HHH is not even allowed to look at its caller.
It is irrelevant whether DDD is the caller of HHH or not.
int main()
{
HHH(DDD);
return;
}
Now HHH is not called from HHH, but has the same input and it should
see that DDD includes the Halt7.c code, which aborts, so it should see:
a halting program.
In other words you fail to understand that
halting requires reaching a final halt state.
On 5/26/2025 3:46 AM, Mikko wrote:
On 2025-05-25 14:53:06 +0000, olcott said:
On 5/25/2025 4:14 AM, Mikko wrote:
On 2025-05-24 15:18:57 +0000, olcott said:
On 5/24/2025 2:47 AM, Mikko wrote:
On 2025-05-23 02:47:40 +0000, olcott changed the subject to
How do computations actually work?
Each computation works differently. It does not matter how it works as >>>>>> long as there are instructions that fully specify how that computation >>>>>> shall be performed.
All termination analyzers are required to report on the
behavior that their input finite string specifies.
To report correctly. Though the input string to a termination analyzer >>>> usially is incomlete: the input string usually specifies different
behavours depending on the input that is not shown to the termination
analyzer, and the analyzer's report must cover all of them.
A partial termination analyzer may fail to report but is not allowed
to report incorrectly.
void DDD()
{
HHH(DDD);
return;
}
DDD simulated by HHH cannot possibly reach its
"return" statement final halt state, only liars
will disagree.
Again a straw man deception. Where reasonable people disgraee is the
relevance of that claim. The behavour specified by DDD does reach the
final return from DDD. Whether HHH can simulate that part of the
behaviour is irrelevant. Even without the simjlation HHH decides
correctly if and only if it determines and reports that DDD halts.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
On 5/27/2025 3:29 AM, Mikko wrote:
On 2025-05-26 16:40:25 +0000, olcott said:
On 5/25/2025 10:46 AM, Fred. Zwarts wrote:
Op 25.mei.2025 om 16:50 schreef olcott:
On 5/25/2025 4:09 AM, Mikko wrote:
On 2025-05-24 15:25:21 +0000, olcott said:
On 5/24/2025 2:54 AM, Mikko wrote:
On 2025-05-23 16:04:49 +0000, olcott said:
On 5/23/2025 2:09 AM, Mikko wrote:
On 2025-05-23 02:47:40 +0000, olcott said:
On 5/22/2025 8:24 PM, Mike Terry wrote:
On 22/05/2025 06:41, Richard Heathfield wrote:
On 22/05/2025 06:23, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 22/05/2025 00:14, olcott wrote:[...]
On 5/21/2025 6:11 PM, Richard Heathfield wrote:
Turing proved that what you're asking is impossible. >>>>>>>>>>>>>>>>>That is not what he proved.
Then you'll be able to write a universal termination >>>>>>>>>>>>>>> analyser that can
correctly report for any program and any input whether it >>>>>>>>>>>>>>> halts. Good
luck with that.
Not necessarily.
Of course not. But I'm just reflecting. He seemed to think >>>>>>>>>>>>> that my inability to write the kind of program Turing >>>>>>>>>>>>> envisaged (an inability that I readily concede) is evidence >>>>>>>>>>>>> for his argument. Well, what's sauce for the goose is sauce >>>>>>>>>>>>> for the gander.
Even if olcott had refuted the proofs of the
insolvability of the Halting Problem -- or even if he had >>>>>>>>>>>>>> proved
that a universal halt decider is possible
And we both know what we both think of that idea.
-- that doesn't imply
that he or anyone else would be able to write one.
Indeed.
I've never been entirely clear on what olcott is claiming. >>>>>>>>>>>>>Nor I. Mike Terry seems to have a pretty good handle on it, >>>>>>>>>>>>> but no matter how clearly he explains it to me my eyes >>>>>>>>>>>>> glaze over and I start to snore.
Hey, it's the way I tell 'em!
Here's what the tabloids might have said about it, if it had >>>>>>>>>>>> made the front pages when the story broke:
COMPUTER BOFFIN IS TURING IN HIS GRAVE!
An Internet crank claims to have refuted Linz HP proof by >>>>>>>>>>>> creating a
Halt Decider that CORRECTLY decides its own "impossible >>>>>>>>>>>> input"!
The computing world is underwhelmed.
Better? (Appologies for the headline, it's the best I could >>>>>>>>>>>> come up with.)
Mike.
There is a key detail about ALL of these proofs
that no one has paid attention to for 90 years.
It is impossible to define *AN INPUT* to HHH that
does the opposite of whatever value that HHH returns.
That is a key detail about HHH. Your HHH is not a part of
those proofs.
All of the proofs work this same way.
No, they don't. Some proofs derive the same conclusion with an >>>>>>>> essentially
different approach.
However, in spite of the differences, they do share a common
fieature:
your HHH is not a part of any of the proofs.
All of the conventional proofs of the HP assume that
there is an *input D* that can actually do the opposite
of whatever value that HHH returns.
Depends on what you mean by "conventional". If you merely mean proofs >>>>>> that apply ordinary logic then there are proofs with a different
strategy. If you mean only proofs that use the same strategy that
Turing used then you are closer to the truth. But there is no
assumption
about the exstence of such D. Its existence is proven.
In seems that way until you pay much closer attention.
int main()
{
DDD(); // The HHH that DDD calls cannot report on the
} // behavior of its caller because it cannot see
// is caller.
Even if HHH could see and report on the behavior of
its caller because its caller is not its input this
too is no good.
It seems that way to you, until you pay somewhat closer attention.
The HHH(DDD) must report on the behavior that its actual input
actually specified CANNOT BE VIOLATED.
Of course it can. In fact HHH does violate that. DDD specifies a halting
behaviour but HHH reports that DDD specifies a non-halting behaviour.
That is a violation of that rquirement.
If DDD simulated by HHH stops running for any
reason besides reaching its own "ret" instruction
final halt state THEN DDD HAS NOT HALTED.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
DDD simulated by HHH cannot possibly reach its own
simulated "ret" instruction final halt state because
this DDD calls its own simulator in recursive simulation.
Ever programmer that has ever heard of recursion should
have gotten this right away. That it is as simple as
recursion and almost no one here gets it leads me to
believe that these reviewers are dishonest.
On 5/27/2025 3:37 AM, Mikko wrote:
On 2025-05-26 15:57:11 +0000, olcott said:
On 5/26/2025 3:46 AM, Mikko wrote:
On 2025-05-25 14:53:06 +0000, olcott said:
On 5/25/2025 4:14 AM, Mikko wrote:
On 2025-05-24 15:18:57 +0000, olcott said:
On 5/24/2025 2:47 AM, Mikko wrote:
On 2025-05-23 02:47:40 +0000, olcott changed the subject to
How do computations actually work?
Each computation works differently. It does not matter how it
works as
long as there are instructions that fully specify how that
computation
shall be performed.
All termination analyzers are required to report on the
behavior that their input finite string specifies.
To report correctly. Though the input string to a termination
analyzer
usially is incomlete: the input string usually specifies different >>>>>> behavours depending on the input that is not shown to the termination >>>>>> analyzer, and the analyzer's report must cover all of them.
A partial termination analyzer may fail to report but is not allowed >>>>>> to report incorrectly.
void DDD()
{
HHH(DDD);
return;
}
DDD simulated by HHH cannot possibly reach its
"return" statement final halt state, only liars
will disagree.
Again a straw man deception. Where reasonable people disgraee is the
relevance of that claim. The behavour specified by DDD does reach the
final return from DDD. Whether HHH can simulate that part of the
behaviour is irrelevant. Even without the simjlation HHH decides
correctly if and only if it determines and reports that DDD halts.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
In order to determine that you need a program that simulates DDD and all
functios DDD calls and detects and counts and reports emulation levels.
No you don't. All that you need to do is simply imagine
that HHH is an x86 emulator capable of emulating itself
emulating DDD. // *This is fully operational code*
We are leaving the number of steps that it emulates up to
you. How many steps will it take for the simulated DDD to
reach its own simulated "ret" instruction final halt state?
On 5/27/2025 3:31 AM, Mikko wrote:
On 2025-05-26 16:26:47 +0000, olcott said:
On 5/26/2025 11:05 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 17:50 schreef olcott:
On 5/26/2025 3:38 AM, Mikko wrote:
On 2025-05-25 14:50:58 +0000, olcott said:
On 5/25/2025 4:09 AM, Mikko wrote:
On 2025-05-24 15:25:21 +0000, olcott said:
On 5/24/2025 2:54 AM, Mikko wrote:
On 2025-05-23 16:04:49 +0000, olcott said:
On 5/23/2025 2:09 AM, Mikko wrote:
On 2025-05-23 02:47:40 +0000, olcott said:
On 5/22/2025 8:24 PM, Mike Terry wrote:That is a key detail about HHH. Your HHH is not a part of >>>>>>>>>>>> those proofs.
On 22/05/2025 06:41, Richard Heathfield wrote:
On 22/05/2025 06:23, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 22/05/2025 00:14, olcott wrote:
On 5/21/2025 6:11 PM, Richard Heathfield wrote: >>>>>>>>>>>>>>>> [...]
Turing proved that what you're asking is impossible. >>>>>>>>>>>>>>>>>>>That is not what he proved.
Then you'll be able to write a universal termination >>>>>>>>>>>>>>>>> analyser that can
correctly report for any program and any input whether >>>>>>>>>>>>>>>>> it halts. Good
luck with that.
Not necessarily.
Of course not. But I'm just reflecting. He seemed to >>>>>>>>>>>>>>> think that my inability to write the kind of program >>>>>>>>>>>>>>> Turing envisaged (an inability that I readily concede) is >>>>>>>>>>>>>>> evidence for his argument. Well, what's sauce for the >>>>>>>>>>>>>>> goose is sauce for the gander.
Even if olcott had refuted the proofs of the
insolvability of the Halting Problem -- or even if he >>>>>>>>>>>>>>>> had proved
that a universal halt decider is possible
And we both know what we both think of that idea. >>>>>>>>>>>>>>>
-- that doesn't implyIndeed.
that he or anyone else would be able to write one. >>>>>>>>>>>>>>>
I've never been entirely clear on what olcott is claiming. >>>>>>>>>>>>>>>Nor I. Mike Terry seems to have a pretty good handle on >>>>>>>>>>>>>>> it, but no matter how clearly he explains it to me my >>>>>>>>>>>>>>> eyes glaze over and I start to snore.
Hey, it's the way I tell 'em!
Here's what the tabloids might have said about it, if it >>>>>>>>>>>>>> had made the front pages when the story broke:
COMPUTER BOFFIN IS TURING IN HIS GRAVE!
An Internet crank claims to have refuted Linz HP proof >>>>>>>>>>>>>> by creating a
Halt Decider that CORRECTLY decides its own "impossible >>>>>>>>>>>>>> input"!
The computing world is underwhelmed.
Better? (Appologies for the headline, it's the best I >>>>>>>>>>>>>> could come up with.)
Mike.
There is a key detail about ALL of these proofs
that no one has paid attention to for 90 years.
It is impossible to define *AN INPUT* to HHH that
does the opposite of whatever value that HHH returns. >>>>>>>>>>>>
All of the proofs work this same way.
No, they don't. Some proofs derive the same conclusion with an >>>>>>>>>> essentially
different approach.
However, in spite of the differences, they do share a common >>>>>>>>>> fieature:
your HHH is not a part of any of the proofs.
All of the conventional proofs of the HP assume that
there is an *input D* that can actually do the opposite
of whatever value that HHH returns.
Depends on what you mean by "conventional". If you merely mean >>>>>>>> proofs
that apply ordinary logic then there are proofs with a different >>>>>>>> strategy. If you mean only proofs that use the same strategy that >>>>>>>> Turing used then you are closer to the truth. But there is no
assumption
about the exstence of such D. Its existence is proven.
In seems that way until you pay much closer attention.
No, it seems that way when you pay enough attention.
int main()
{
DDD(); // The HHH that DDD calls cannot report on the
} // behavior of its caller because it cannot see
// is caller.
If HHH is correctly constructed it does see DDD and everything DDD >>>>>> calls. Nothing else is relevant.
Try to show how HHH can see anything about its own caller
when HHH is not even allowed to look at its caller.
It is irrelevant whether DDD is the caller of HHH or not.
int main()
{
HHH(DDD);
return;
}
Now HHH is not called from HHH, but has the same input and it should
see that DDD includes the Halt7.c code, which aborts, so it should
see: a halting program.
In other words you fail to understand that
halting requires reaching a final halt state.
It is a sin to present false claims about tother peoples understanding.
You have acted like you don't know this.
On 5/27/2025 3:29 AM, Mikko wrote:
On 2025-05-26 16:40:25 +0000, olcott said:
On 5/25/2025 10:46 AM, Fred. Zwarts wrote:
Op 25.mei.2025 om 16:50 schreef olcott:
On 5/25/2025 4:09 AM, Mikko wrote:
On 2025-05-24 15:25:21 +0000, olcott said:
On 5/24/2025 2:54 AM, Mikko wrote:
On 2025-05-23 16:04:49 +0000, olcott said:
On 5/23/2025 2:09 AM, Mikko wrote:
On 2025-05-23 02:47:40 +0000, olcott said:
On 5/22/2025 8:24 PM, Mike Terry wrote:
On 22/05/2025 06:41, Richard Heathfield wrote:
On 22/05/2025 06:23, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 22/05/2025 00:14, olcott wrote:[...]
On 5/21/2025 6:11 PM, Richard Heathfield wrote:
Turing proved that what you're asking is impossible. >>>>>>>>>>>>>>>>>That is not what he proved.
Then you'll be able to write a universal termination analyser that can
correctly report for any program and any input whether it halts. Good
luck with that.
Not necessarily.
Of course not. But I'm just reflecting. He seemed to think that my
inability to write the kind of program Turing envisaged (an inability
that I readily concede) is evidence for his argument. Well, what's
sauce for the goose is sauce for the gander.
Even if olcott had refuted the proofs of the
insolvability of the Halting Problem -- or even if he had proved >>>>>>>>>>>>>> that a universal halt decider is possible
And we both know what we both think of that idea.
-- that doesn't imply
that he or anyone else would be able to write one.
Indeed.
I've never been entirely clear on what olcott is claiming. >>>>>>>>>>>>>Nor I. Mike Terry seems to have a pretty good handle on it, but no
matter how clearly he explains it to me my eyes glaze over and I start
to snore.
Hey, it's the way I tell 'em!
Here's what the tabloids might have said about it, if it had made the
front pages when the story broke:
COMPUTER BOFFIN IS TURING IN HIS GRAVE!
An Internet crank claims to have refuted Linz HP proof by creating a
Halt Decider that CORRECTLY decides its own "impossible input"! >>>>>>>>>>>> The computing world is underwhelmed.
Better? (Appologies for the headline, it's the best I could come up with.)
Mike.
There is a key detail about ALL of these proofs
that no one has paid attention to for 90 years.
It is impossible to define *AN INPUT* to HHH that
does the opposite of whatever value that HHH returns.
That is a key detail about HHH. Your HHH is not a part of those proofs.
All of the proofs work this same way.
No, they don't. Some proofs derive the same conclusion with an essentially
different approach.
However, in spite of the differences, they do share a common fieature: >>>>>>>> your HHH is not a part of any of the proofs.
All of the conventional proofs of the HP assume that
there is an *input D* that can actually do the opposite
of whatever value that HHH returns.
Depends on what you mean by "conventional". If you merely mean proofs >>>>>> that apply ordinary logic then there are proofs with a different
strategy. If you mean only proofs that use the same strategy that
Turing used then you are closer to the truth. But there is no assumption >>>>>> about the exstence of such D. Its existence is proven.
In seems that way until you pay much closer attention.
int main()
{
DDD(); // The HHH that DDD calls cannot report on the
} // behavior of its caller because it cannot see
// is caller.
Even if HHH could see and report on the behavior of
its caller because its caller is not its input this
too is no good.
It seems that way to you, until you pay somewhat closer attention.
The HHH(DDD) must report on the behavior that its actual input
actually specified CANNOT BE VIOLATED.
Of course it can. In fact HHH does violate that. DDD specifies a halting
behaviour but HHH reports that DDD specifies a non-halting behaviour.
That is a violation of that rquirement.
If DDD simulated by HHH stops running for any
reason besides reaching its own "ret" instruction
final halt state THEN DDD HAS NOT HALTED.
On 5/27/2025 3:37 AM, Mikko wrote:
On 2025-05-26 15:57:11 +0000, olcott said:
On 5/26/2025 3:46 AM, Mikko wrote:
On 2025-05-25 14:53:06 +0000, olcott said:
On 5/25/2025 4:14 AM, Mikko wrote:
On 2025-05-24 15:18:57 +0000, olcott said:
On 5/24/2025 2:47 AM, Mikko wrote:
On 2025-05-23 02:47:40 +0000, olcott changed the subject to
How do computations actually work?
Each computation works differently. It does not matter how it works as >>>>>>>> long as there are instructions that fully specify how that computation >>>>>>>> shall be performed.
All termination analyzers are required to report on the
behavior that their input finite string specifies.
To report correctly. Though the input string to a termination analyzer >>>>>> usially is incomlete: the input string usually specifies different >>>>>> behavours depending on the input that is not shown to the termination >>>>>> analyzer, and the analyzer's report must cover all of them.
A partial termination analyzer may fail to report but is not allowed >>>>>> to report incorrectly.
void DDD()
{
HHH(DDD);
return;
}
DDD simulated by HHH cannot possibly reach its
"return" statement final halt state, only liars
will disagree.
Again a straw man deception. Where reasonable people disgraee is the
relevance of that claim. The behavour specified by DDD does reach the
final return from DDD. Whether HHH can simulate that part of the
behaviour is irrelevant. Even without the simjlation HHH decides
correctly if and only if it determines and reports that DDD halts.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
In order to determine that you need a program that simulates DDD and all
functios DDD calls and detects and counts and reports emulation levels.
No you don't. All that you need to do is simply imagine
that HHH is an x86 emulator capable of emulating itself
emulating DDD. // *This is fully operational code*
On 5/27/2025 3:31 AM, Mikko wrote:
On 2025-05-26 16:26:47 +0000, olcott said:
On 5/26/2025 11:05 AM, Fred. Zwarts wrote:
Op 26.mei.2025 om 17:50 schreef olcott:
On 5/26/2025 3:38 AM, Mikko wrote:
On 2025-05-25 14:50:58 +0000, olcott said:
On 5/25/2025 4:09 AM, Mikko wrote:
On 2025-05-24 15:25:21 +0000, olcott said:
On 5/24/2025 2:54 AM, Mikko wrote:
On 2025-05-23 16:04:49 +0000, olcott said:
On 5/23/2025 2:09 AM, Mikko wrote:
On 2025-05-23 02:47:40 +0000, olcott said:
On 5/22/2025 8:24 PM, Mike Terry wrote:That is a key detail about HHH. Your HHH is not a part of those proofs.
On 22/05/2025 06:41, Richard Heathfield wrote:
On 22/05/2025 06:23, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 22/05/2025 00:14, olcott wrote:
On 5/21/2025 6:11 PM, Richard Heathfield wrote: >>>>>>>>>>>>>>>> [...]
Turing proved that what you're asking is impossible. >>>>>>>>>>>>>>>>>>>That is not what he proved.
Then you'll be able to write a universal termination analyser that can
correctly report for any program and any input whether it halts. Good
luck with that.
Not necessarily.
Of course not. But I'm just reflecting. He seemed to think that my
inability to write the kind of program Turing envisaged (an inability
that I readily concede) is evidence for his argument. Well, what's
sauce for the goose is sauce for the gander.
Even if olcott had refuted the proofs of the
insolvability of the Halting Problem -- or even if he had proved
that a universal halt decider is possible
And we both know what we both think of that idea. >>>>>>>>>>>>>>>
-- that doesn't implyIndeed.
that he or anyone else would be able to write one. >>>>>>>>>>>>>>>
I've never been entirely clear on what olcott is claiming. >>>>>>>>>>>>>>>Nor I. Mike Terry seems to have a pretty good handle on it, but no
matter how clearly he explains it to me my eyes glaze over and I start
to snore.
Hey, it's the way I tell 'em!
Here's what the tabloids might have said about it, if it had made the
front pages when the story broke:
COMPUTER BOFFIN IS TURING IN HIS GRAVE!
An Internet crank claims to have refuted Linz HP proof by creating a
Halt Decider that CORRECTLY decides its own "impossible input"!
The computing world is underwhelmed.
Better? (Appologies for the headline, it's the best I could come up with.)
Mike.
There is a key detail about ALL of these proofs
that no one has paid attention to for 90 years.
It is impossible to define *AN INPUT* to HHH that
does the opposite of whatever value that HHH returns. >>>>>>>>>>>>
All of the proofs work this same way.
No, they don't. Some proofs derive the same conclusion with an essentially
different approach.
However, in spite of the differences, they do share a common fieature:
your HHH is not a part of any of the proofs.
All of the conventional proofs of the HP assume that
there is an *input D* that can actually do the opposite
of whatever value that HHH returns.
Depends on what you mean by "conventional". If you merely mean proofs >>>>>>>> that apply ordinary logic then there are proofs with a different >>>>>>>> strategy. If you mean only proofs that use the same strategy that >>>>>>>> Turing used then you are closer to the truth. But there is no assumption
about the exstence of such D. Its existence is proven.
In seems that way until you pay much closer attention.
No, it seems that way when you pay enough attention.
int main()
{
DDD(); // The HHH that DDD calls cannot report on the
} // behavior of its caller because it cannot see
// is caller.
If HHH is correctly constructed it does see DDD and everything DDD >>>>>> calls. Nothing else is relevant.
Try to show how HHH can see anything about its own caller
when HHH is not even allowed to look at its caller.
It is irrelevant whether DDD is the caller of HHH or not.
int main()
{
HHH(DDD);
return;
}
Now HHH is not called from HHH, but has the same input and it should
see that DDD includes the Halt7.c code, which aborts, so it should see: >>>> a halting program.
In other words you fail to understand that
halting requires reaching a final halt state.
It is a sin to present false claims about tother peoples understanding.
You have acted like you don't know this.
On 5/28/2025 2:36 AM, Mikko wrote:
On 2025-05-27 15:40:33 +0000, olcott said:
On 5/27/2025 3:29 AM, Mikko wrote:
On 2025-05-26 16:40:25 +0000, olcott said:
On 5/25/2025 10:46 AM, Fred. Zwarts wrote:
Op 25.mei.2025 om 16:50 schreef olcott:
On 5/25/2025 4:09 AM, Mikko wrote:
On 2025-05-24 15:25:21 +0000, olcott said:
On 5/24/2025 2:54 AM, Mikko wrote:
On 2025-05-23 16:04:49 +0000, olcott said:
On 5/23/2025 2:09 AM, Mikko wrote:
On 2025-05-23 02:47:40 +0000, olcott said:
On 5/22/2025 8:24 PM, Mike Terry wrote:That is a key detail about HHH. Your HHH is not a part of >>>>>>>>>>>> those proofs.
On 22/05/2025 06:41, Richard Heathfield wrote:
On 22/05/2025 06:23, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 22/05/2025 00:14, olcott wrote:
On 5/21/2025 6:11 PM, Richard Heathfield wrote: >>>>>>>>>>>>>>>> [...]
Turing proved that what you're asking is impossible. >>>>>>>>>>>>>>>>>>>That is not what he proved.
Then you'll be able to write a universal termination >>>>>>>>>>>>>>>>> analyser that can
correctly report for any program and any input whether >>>>>>>>>>>>>>>>> it halts. Good
luck with that.
Not necessarily.
Of course not. But I'm just reflecting. He seemed to >>>>>>>>>>>>>>> think that my inability to write the kind of program >>>>>>>>>>>>>>> Turing envisaged (an inability that I readily concede) is >>>>>>>>>>>>>>> evidence for his argument. Well, what's sauce for the >>>>>>>>>>>>>>> goose is sauce for the gander.
Even if olcott had refuted the proofs of the
insolvability of the Halting Problem -- or even if he >>>>>>>>>>>>>>>> had proved
that a universal halt decider is possible
And we both know what we both think of that idea. >>>>>>>>>>>>>>>
-- that doesn't implyIndeed.
that he or anyone else would be able to write one. >>>>>>>>>>>>>>>
I've never been entirely clear on what olcott is claiming. >>>>>>>>>>>>>>>Nor I. Mike Terry seems to have a pretty good handle on >>>>>>>>>>>>>>> it, but no matter how clearly he explains it to me my >>>>>>>>>>>>>>> eyes glaze over and I start to snore.
Hey, it's the way I tell 'em!
Here's what the tabloids might have said about it, if it >>>>>>>>>>>>>> had made the front pages when the story broke:
COMPUTER BOFFIN IS TURING IN HIS GRAVE!
An Internet crank claims to have refuted Linz HP proof >>>>>>>>>>>>>> by creating a
Halt Decider that CORRECTLY decides its own "impossible >>>>>>>>>>>>>> input"!
The computing world is underwhelmed.
Better? (Appologies for the headline, it's the best I >>>>>>>>>>>>>> could come up with.)
Mike.
There is a key detail about ALL of these proofs
that no one has paid attention to for 90 years.
It is impossible to define *AN INPUT* to HHH that
does the opposite of whatever value that HHH returns. >>>>>>>>>>>>
All of the proofs work this same way.
No, they don't. Some proofs derive the same conclusion with an >>>>>>>>>> essentially
different approach.
However, in spite of the differences, they do share a common >>>>>>>>>> fieature:
your HHH is not a part of any of the proofs.
All of the conventional proofs of the HP assume that
there is an *input D* that can actually do the opposite
of whatever value that HHH returns.
Depends on what you mean by "conventional". If you merely mean >>>>>>>> proofs
that apply ordinary logic then there are proofs with a different >>>>>>>> strategy. If you mean only proofs that use the same strategy that >>>>>>>> Turing used then you are closer to the truth. But there is no
assumption
about the exstence of such D. Its existence is proven.
In seems that way until you pay much closer attention.
int main()
{
DDD(); // The HHH that DDD calls cannot report on the
} // behavior of its caller because it cannot see
// is caller.
Even if HHH could see and report on the behavior of
its caller because its caller is not its input this
too is no good.
It seems that way to you, until you pay somewhat closer attention.
The HHH(DDD) must report on the behavior that its actual input
actually specified CANNOT BE VIOLATED.
Of course it can. In fact HHH does violate that. DDD specifies a
halting
behaviour but HHH reports that DDD specifies a non-halting behaviour.
That is a violation of that rquirement.
If DDD simulated by HHH stops running for any
reason besides reaching its own "ret" instruction
final halt state THEN DDD HAS NOT HALTED.
Irrelevant. The requirement is that a halt decider predicts whether the
complete execution of the computation described by the input will halt.
Halting is defined as reaching a final state and
terminating normally.
int main()
{
DDD(); // The HHH that DDD calls cannot
} // see the behavior of its caller
*That is incorrect*
A termination analyzer must report on the basis
of the behavior that its input specifies and does
not give a rat's ass about the behavior of its caller.
_DDD()If the input specifies a halting program, such as in this case, this is
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
It is a tautology that every input to a simulating
termination analyzer would never stop running unless
aborted specifies a non-terminating sequence of
configurations.
On 5/28/2025 2:36 AM, Mikko wrote:
On 2025-05-27 15:40:33 +0000, olcott said:
On 5/27/2025 3:29 AM, Mikko wrote:
On 2025-05-26 16:40:25 +0000, olcott said:
On 5/25/2025 10:46 AM, Fred. Zwarts wrote:
Op 25.mei.2025 om 16:50 schreef olcott:
On 5/25/2025 4:09 AM, Mikko wrote:
On 2025-05-24 15:25:21 +0000, olcott said:
On 5/24/2025 2:54 AM, Mikko wrote:
On 2025-05-23 16:04:49 +0000, olcott said:
On 5/23/2025 2:09 AM, Mikko wrote:
On 2025-05-23 02:47:40 +0000, olcott said:
On 5/22/2025 8:24 PM, Mike Terry wrote:That is a key detail about HHH. Your HHH is not a part of those proofs.
On 22/05/2025 06:41, Richard Heathfield wrote:
On 22/05/2025 06:23, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 22/05/2025 00:14, olcott wrote:
On 5/21/2025 6:11 PM, Richard Heathfield wrote: >>>>>>>>>>>>>>>> [...]
Turing proved that what you're asking is impossible. >>>>>>>>>>>>>>>>>>>That is not what he proved.
Then you'll be able to write a universal termination analyser that can
correctly report for any program and any input whether it halts. Good
luck with that.
Not necessarily.
Of course not. But I'm just reflecting. He seemed to think that my
inability to write the kind of program Turing envisaged (an inability
that I readily concede) is evidence for his argument. Well, what's
sauce for the goose is sauce for the gander.
Even if olcott had refuted the proofs of the
insolvability of the Halting Problem -- or even if he had proved
that a universal halt decider is possible
And we both know what we both think of that idea. >>>>>>>>>>>>>>>
-- that doesn't implyIndeed.
that he or anyone else would be able to write one. >>>>>>>>>>>>>>>
I've never been entirely clear on what olcott is claiming. >>>>>>>>>>>>>>>Nor I. Mike Terry seems to have a pretty good handle on it, but no
matter how clearly he explains it to me my eyes glaze over and I start
to snore.
Hey, it's the way I tell 'em!
Here's what the tabloids might have said about it, if it had made the
front pages when the story broke:
COMPUTER BOFFIN IS TURING IN HIS GRAVE!
An Internet crank claims to have refuted Linz HP proof by creating a
Halt Decider that CORRECTLY decides its own "impossible input"!
The computing world is underwhelmed.
Better? (Appologies for the headline, it's the best I could come up with.)
Mike.
There is a key detail about ALL of these proofs
that no one has paid attention to for 90 years.
It is impossible to define *AN INPUT* to HHH that
does the opposite of whatever value that HHH returns. >>>>>>>>>>>>
All of the proofs work this same way.
No, they don't. Some proofs derive the same conclusion with an essentially
different approach.
However, in spite of the differences, they do share a common fieature:
your HHH is not a part of any of the proofs.
All of the conventional proofs of the HP assume that
there is an *input D* that can actually do the opposite
of whatever value that HHH returns.
Depends on what you mean by "conventional". If you merely mean proofs >>>>>>>> that apply ordinary logic then there are proofs with a different >>>>>>>> strategy. If you mean only proofs that use the same strategy that >>>>>>>> Turing used then you are closer to the truth. But there is no assumption
about the exstence of such D. Its existence is proven.
In seems that way until you pay much closer attention.
int main()
{
DDD(); // The HHH that DDD calls cannot report on the
} // behavior of its caller because it cannot see
// is caller.
Even if HHH could see and report on the behavior of
its caller because its caller is not its input this
too is no good.
It seems that way to you, until you pay somewhat closer attention.
The HHH(DDD) must report on the behavior that its actual input
actually specified CANNOT BE VIOLATED.
Of course it can. In fact HHH does violate that. DDD specifies a halting >>>> behaviour but HHH reports that DDD specifies a non-halting behaviour.
That is a violation of that rquirement.
If DDD simulated by HHH stops running for any
reason besides reaching its own "ret" instruction
final halt state THEN DDD HAS NOT HALTED.
Irrelevant. The requirement is that a halt decider predicts whether the
complete execution of the computation described by the input will halt.
Halting is defined as reaching a final state and
terminating normally.
The usual meaning of halting is reaching a state where the
computation cannot be computed.
On 5/28/2025 2:36 AM, Mikko wrote:
On 2025-05-27 15:40:33 +0000, olcott said:
On 5/27/2025 3:29 AM, Mikko wrote:
On 2025-05-26 16:40:25 +0000, olcott said:
On 5/25/2025 10:46 AM, Fred. Zwarts wrote:
Op 25.mei.2025 om 16:50 schreef olcott:
On 5/25/2025 4:09 AM, Mikko wrote:
On 2025-05-24 15:25:21 +0000, olcott said:
On 5/24/2025 2:54 AM, Mikko wrote:
On 2025-05-23 16:04:49 +0000, olcott said:
On 5/23/2025 2:09 AM, Mikko wrote:
On 2025-05-23 02:47:40 +0000, olcott said:
On 5/22/2025 8:24 PM, Mike Terry wrote:That is a key detail about HHH. Your HHH is not a part of >>>>>>>>>>>> those proofs.
On 22/05/2025 06:41, Richard Heathfield wrote:
On 22/05/2025 06:23, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 22/05/2025 00:14, olcott wrote:
On 5/21/2025 6:11 PM, Richard Heathfield wrote: >>>>>>>>>>>>>>>> [...]
Turing proved that what you're asking is impossible. >>>>>>>>>>>>>>>>>>>That is not what he proved.
Then you'll be able to write a universal termination >>>>>>>>>>>>>>>>> analyser that can
correctly report for any program and any input whether >>>>>>>>>>>>>>>>> it halts. Good
luck with that.
Not necessarily.
Of course not. But I'm just reflecting. He seemed to >>>>>>>>>>>>>>> think that my inability to write the kind of program >>>>>>>>>>>>>>> Turing envisaged (an inability that I readily concede) is >>>>>>>>>>>>>>> evidence for his argument. Well, what's sauce for the >>>>>>>>>>>>>>> goose is sauce for the gander.
Even if olcott had refuted the proofs of the
insolvability of the Halting Problem -- or even if he >>>>>>>>>>>>>>>> had proved
that a universal halt decider is possible
And we both know what we both think of that idea. >>>>>>>>>>>>>>>
-- that doesn't implyIndeed.
that he or anyone else would be able to write one. >>>>>>>>>>>>>>>
I've never been entirely clear on what olcott is claiming. >>>>>>>>>>>>>>>Nor I. Mike Terry seems to have a pretty good handle on >>>>>>>>>>>>>>> it, but no matter how clearly he explains it to me my >>>>>>>>>>>>>>> eyes glaze over and I start to snore.
Hey, it's the way I tell 'em!
Here's what the tabloids might have said about it, if it >>>>>>>>>>>>>> had made the front pages when the story broke:
COMPUTER BOFFIN IS TURING IN HIS GRAVE!
An Internet crank claims to have refuted Linz HP proof >>>>>>>>>>>>>> by creating a
Halt Decider that CORRECTLY decides its own "impossible >>>>>>>>>>>>>> input"!
The computing world is underwhelmed.
Better? (Appologies for the headline, it's the best I >>>>>>>>>>>>>> could come up with.)
Mike.
There is a key detail about ALL of these proofs
that no one has paid attention to for 90 years.
It is impossible to define *AN INPUT* to HHH that
does the opposite of whatever value that HHH returns. >>>>>>>>>>>>
All of the proofs work this same way.
No, they don't. Some proofs derive the same conclusion with an >>>>>>>>>> essentially
different approach.
However, in spite of the differences, they do share a common >>>>>>>>>> fieature:
your HHH is not a part of any of the proofs.
All of the conventional proofs of the HP assume that
there is an *input D* that can actually do the opposite
of whatever value that HHH returns.
Depends on what you mean by "conventional". If you merely mean >>>>>>>> proofs
that apply ordinary logic then there are proofs with a different >>>>>>>> strategy. If you mean only proofs that use the same strategy that >>>>>>>> Turing used then you are closer to the truth. But there is no
assumption
about the exstence of such D. Its existence is proven.
In seems that way until you pay much closer attention.
int main()
{
DDD(); // The HHH that DDD calls cannot report on the
} // behavior of its caller because it cannot see
// is caller.
Even if HHH could see and report on the behavior of
its caller because its caller is not its input this
too is no good.
It seems that way to you, until you pay somewhat closer attention.
The HHH(DDD) must report on the behavior that its actual input
actually specified CANNOT BE VIOLATED.
Of course it can. In fact HHH does violate that. DDD specifies a
halting
behaviour but HHH reports that DDD specifies a non-halting behaviour.
That is a violation of that rquirement.
If DDD simulated by HHH stops running for any
reason besides reaching its own "ret" instruction
final halt state THEN DDD HAS NOT HALTED.
Irrelevant. The requirement is that a halt decider predicts whether the
complete execution of the computation described by the input will halt.
Halting is defined as reaching a final state and
terminating normally.
int main()
{
DDD(); // The HHH that DDD calls cannot
} // see the behavior of its caller
*That is incorrect*
A termination analyzer must report on the basis
of the behavior that its input specifies and does
not give a rat's ass about the behavior of its caller.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
It is a tautology that every input to a simulating
termination analyzer would never stop running unless
aborted specifies a non-terminating sequence of
configurations.
On 5/28/2025 2:43 AM, Mikko wrote:
On 2025-05-27 15:48:14 +0000, olcott said:
On 5/27/2025 3:37 AM, Mikko wrote:
On 2025-05-26 15:57:11 +0000, olcott said:No you don't. All that you need to do is simply imagine
On 5/26/2025 3:46 AM, Mikko wrote:
On 2025-05-25 14:53:06 +0000, olcott said:
On 5/25/2025 4:14 AM, Mikko wrote:
On 2025-05-24 15:18:57 +0000, olcott said:
On 5/24/2025 2:47 AM, Mikko wrote:
On 2025-05-23 02:47:40 +0000, olcott changed the subject to >>>>>>>>>>> How do computations actually work?
Each computation works differently. It does not matter how it >>>>>>>>>> works as
long as there are instructions that fully specify how that >>>>>>>>>> computation
shall be performed.
All termination analyzers are required to report on the
behavior that their input finite string specifies.
To report correctly. Though the input string to a termination
analyzer
usially is incomlete: the input string usually specifies different >>>>>>>> behavours depending on the input that is not shown to the
termination
analyzer, and the analyzer's report must cover all of them.
A partial termination analyzer may fail to report but is not
allowed
to report incorrectly.
void DDD()
{
HHH(DDD);
return;
}
DDD simulated by HHH cannot possibly reach its
"return" statement final halt state, only liars
will disagree.
Again a straw man deception. Where reasonable people disgraee is the >>>>>> relevance of that claim. The behavour specified by DDD does reach the >>>>>> final return from DDD. Whether HHH can simulate that part of the
behaviour is irrelevant. Even without the simjlation HHH decides
correctly if and only if it determines and reports that DDD halts.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
In order to determine that you need a program that simulates DDD and
all
functios DDD calls and detects and counts and reports emulation levels. >>>
that HHH is an x86 emulator capable of emulating itself
emulating DDD. // *This is fully operational code*
Well, you needn't if you have a good substitution. But imagination is
not a good substitution of real work with a real tool.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
has an HHH that does simulate itself simulating DDD.
On 5/28/2025 2:13 PM, Fred. Zwarts wrote:
Op 28.mei.2025 om 16:31 schreef olcott:
On 5/28/2025 2:36 AM, Mikko wrote:
On 2025-05-27 15:40:33 +0000, olcott said:
On 5/27/2025 3:29 AM, Mikko wrote:
On 2025-05-26 16:40:25 +0000, olcott said:
On 5/25/2025 10:46 AM, Fred. Zwarts wrote:
Op 25.mei.2025 om 16:50 schreef olcott:The HHH(DDD) must report on the behavior that its actual input
On 5/25/2025 4:09 AM, Mikko wrote:
On 2025-05-24 15:25:21 +0000, olcott said:
On 5/24/2025 2:54 AM, Mikko wrote:
On 2025-05-23 16:04:49 +0000, olcott said:
On 5/23/2025 2:09 AM, Mikko wrote:
On 2025-05-23 02:47:40 +0000, olcott said:
On 5/22/2025 8:24 PM, Mike Terry wrote:That is a key detail about HHH. Your HHH is not a part of >>>>>>>>>>>>>> those proofs.
On 22/05/2025 06:41, Richard Heathfield wrote: >>>>>>>>>>>>>>>>> On 22/05/2025 06:23, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes: >>>>>>>>>>>>>>>>>>> On 22/05/2025 00:14, olcott wrote:
On 5/21/2025 6:11 PM, Richard Heathfield wrote: >>>>>>>>>>>>>>>>>> [...]
Turing proved that what you're asking is impossible. >>>>>>>>>>>>>>>>>>>>>That is not what he proved.
Then you'll be able to write a universal termination >>>>>>>>>>>>>>>>>>> analyser that can
correctly report for any program and any input >>>>>>>>>>>>>>>>>>> whether it halts. Good
luck with that.
Not necessarily.
Of course not. But I'm just reflecting. He seemed to >>>>>>>>>>>>>>>>> think that my inability to write the kind of program >>>>>>>>>>>>>>>>> Turing envisaged (an inability that I readily concede) >>>>>>>>>>>>>>>>> is evidence for his argument. Well, what's sauce for >>>>>>>>>>>>>>>>> the goose is sauce for the gander.
Even if olcott had refuted the proofs of the >>>>>>>>>>>>>>>>>> insolvability of the Halting Problem -- or even if he >>>>>>>>>>>>>>>>>> had proved
that a universal halt decider is possible
And we both know what we both think of that idea. >>>>>>>>>>>>>>>>>
-- that doesn't implyIndeed.
that he or anyone else would be able to write one. >>>>>>>>>>>>>>>>>
I've never been entirely clear on what olcott is >>>>>>>>>>>>>>>>>> claiming.
Nor I. Mike Terry seems to have a pretty good handle on >>>>>>>>>>>>>>>>> it, but no matter how clearly he explains it to me my >>>>>>>>>>>>>>>>> eyes glaze over and I start to snore.
Hey, it's the way I tell 'em!
Here's what the tabloids might have said about it, if it >>>>>>>>>>>>>>>> had made the front pages when the story broke: >>>>>>>>>>>>>>>>
COMPUTER BOFFIN IS TURING IN HIS GRAVE!
An Internet crank claims to have refuted Linz HP proof >>>>>>>>>>>>>>>> by creating a
Halt Decider that CORRECTLY decides its own >>>>>>>>>>>>>>>> "impossible input"!
The computing world is underwhelmed.
Better? (Appologies for the headline, it's the best I >>>>>>>>>>>>>>>> could come up with.)
Mike.
There is a key detail about ALL of these proofs
that no one has paid attention to for 90 years.
It is impossible to define *AN INPUT* to HHH that >>>>>>>>>>>>>>> does the opposite of whatever value that HHH returns. >>>>>>>>>>>>>>
All of the proofs work this same way.
No, they don't. Some proofs derive the same conclusion with >>>>>>>>>>>> an essentially
different approach.
However, in spite of the differences, they do share a common >>>>>>>>>>>> fieature:
your HHH is not a part of any of the proofs.
All of the conventional proofs of the HP assume that
there is an *input D* that can actually do the opposite
of whatever value that HHH returns.
Depends on what you mean by "conventional". If you merely mean >>>>>>>>>> proofs
that apply ordinary logic then there are proofs with a different >>>>>>>>>> strategy. If you mean only proofs that use the same strategy that >>>>>>>>>> Turing used then you are closer to the truth. But there is no >>>>>>>>>> assumption
about the exstence of such D. Its existence is proven.
In seems that way until you pay much closer attention.
int main()
{
DDD(); // The HHH that DDD calls cannot report on the
} // behavior of its caller because it cannot see >>>>>>>>> // is caller.
Even if HHH could see and report on the behavior of
its caller because its caller is not its input this
too is no good.
It seems that way to you, until you pay somewhat closer attention. >>>>>>>
actually specified CANNOT BE VIOLATED.
Of course it can. In fact HHH does violate that. DDD specifies a
halting
behaviour but HHH reports that DDD specifies a non-halting behaviour. >>>>>> That is a violation of that rquirement.
If DDD simulated by HHH stops running for any
reason besides reaching its own "ret" instruction
final halt state THEN DDD HAS NOT HALTED.
Irrelevant. The requirement is that a halt decider predicts whether the >>>> complete execution of the computation described by the input will halt. >>>>
Halting is defined as reaching a final state and
terminating normally.
So, according to this definition, every simulator that aborts after
one instruction is correct to report a non-halting program.
int main()
{
DDD(); // The HHH that DDD calls cannot
} // see the behavior of its caller
*That is incorrect*
A termination analyzer must report on the basis
of the behavior that its input specifies and does
not give a rat's ass about the behavior of its caller.
The caller is not of any interest. The analyser must report on the
input. In this case the anaylzer is given a pointer to memory as
input. This contains the code of DDD. That code has addresses, among
others in call instructions, that gives the analyser access to other
parts of the memory. In this way the analyser should analyse the whole
program, including the code that aborts and halt. If done correctly,
it will see that the input specifies a halting program.
If the input specifies a halting program, such as in this case, this
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
It is a tautology that every input to a simulating
termination analyzer would never stop running unless
aborted specifies a non-terminating sequence of
configurations.
is a vacuous statement. It does not need an abort, because the input
already specifies an abort, which makes the simulation halt, if done
correctly.
You continue to act as if when you are starving
hungry that the fact you won't be hungry after
you have eaten means that you never have to eat.
On 5/28/2025 2:13 PM, Fred. Zwarts wrote:
Op 28.mei.2025 om 16:31 schreef olcott:
On 5/28/2025 2:36 AM, Mikko wrote:
On 2025-05-27 15:40:33 +0000, olcott said:
On 5/27/2025 3:29 AM, Mikko wrote:
On 2025-05-26 16:40:25 +0000, olcott said:
On 5/25/2025 10:46 AM, Fred. Zwarts wrote:
Op 25.mei.2025 om 16:50 schreef olcott:The HHH(DDD) must report on the behavior that its actual input
On 5/25/2025 4:09 AM, Mikko wrote:
On 2025-05-24 15:25:21 +0000, olcott said:
On 5/24/2025 2:54 AM, Mikko wrote:
On 2025-05-23 16:04:49 +0000, olcott said:
On 5/23/2025 2:09 AM, Mikko wrote:
On 2025-05-23 02:47:40 +0000, olcott said:
On 5/22/2025 8:24 PM, Mike Terry wrote:That is a key detail about HHH. Your HHH is not a part of >>>>>>>>>>>>>> those proofs.
On 22/05/2025 06:41, Richard Heathfield wrote: >>>>>>>>>>>>>>>>> On 22/05/2025 06:23, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes: >>>>>>>>>>>>>>>>>>> On 22/05/2025 00:14, olcott wrote:
On 5/21/2025 6:11 PM, Richard Heathfield wrote: >>>>>>>>>>>>>>>>>> [...]
Turing proved that what you're asking is impossible. >>>>>>>>>>>>>>>>>>>>>That is not what he proved.
Then you'll be able to write a universal termination >>>>>>>>>>>>>>>>>>> analyser that can
correctly report for any program and any input >>>>>>>>>>>>>>>>>>> whether it halts. Good
luck with that.
Not necessarily.
Of course not. But I'm just reflecting. He seemed to >>>>>>>>>>>>>>>>> think that my inability to write the kind of program >>>>>>>>>>>>>>>>> Turing envisaged (an inability that I readily concede) >>>>>>>>>>>>>>>>> is evidence for his argument. Well, what's sauce for >>>>>>>>>>>>>>>>> the goose is sauce for the gander.
Even if olcott had refuted the proofs of the >>>>>>>>>>>>>>>>>> insolvability of the Halting Problem -- or even if he >>>>>>>>>>>>>>>>>> had proved
that a universal halt decider is possible
And we both know what we both think of that idea. >>>>>>>>>>>>>>>>>
-- that doesn't implyIndeed.
that he or anyone else would be able to write one. >>>>>>>>>>>>>>>>>
I've never been entirely clear on what olcott is >>>>>>>>>>>>>>>>>> claiming.
Nor I. Mike Terry seems to have a pretty good handle on >>>>>>>>>>>>>>>>> it, but no matter how clearly he explains it to me my >>>>>>>>>>>>>>>>> eyes glaze over and I start to snore.
Hey, it's the way I tell 'em!
Here's what the tabloids might have said about it, if it >>>>>>>>>>>>>>>> had made the front pages when the story broke: >>>>>>>>>>>>>>>>
COMPUTER BOFFIN IS TURING IN HIS GRAVE!
An Internet crank claims to have refuted Linz HP proof >>>>>>>>>>>>>>>> by creating a
Halt Decider that CORRECTLY decides its own >>>>>>>>>>>>>>>> "impossible input"!
The computing world is underwhelmed.
Better? (Appologies for the headline, it's the best I >>>>>>>>>>>>>>>> could come up with.)
Mike.
There is a key detail about ALL of these proofs
that no one has paid attention to for 90 years.
It is impossible to define *AN INPUT* to HHH that >>>>>>>>>>>>>>> does the opposite of whatever value that HHH returns. >>>>>>>>>>>>>>
All of the proofs work this same way.
No, they don't. Some proofs derive the same conclusion with >>>>>>>>>>>> an essentially
different approach.
However, in spite of the differences, they do share a common >>>>>>>>>>>> fieature:
your HHH is not a part of any of the proofs.
All of the conventional proofs of the HP assume that
there is an *input D* that can actually do the opposite
of whatever value that HHH returns.
Depends on what you mean by "conventional". If you merely mean >>>>>>>>>> proofs
that apply ordinary logic then there are proofs with a different >>>>>>>>>> strategy. If you mean only proofs that use the same strategy that >>>>>>>>>> Turing used then you are closer to the truth. But there is no >>>>>>>>>> assumption
about the exstence of such D. Its existence is proven.
In seems that way until you pay much closer attention.
int main()
{
DDD(); // The HHH that DDD calls cannot report on the
} // behavior of its caller because it cannot see >>>>>>>>> // is caller.
Even if HHH could see and report on the behavior of
its caller because its caller is not its input this
too is no good.
It seems that way to you, until you pay somewhat closer attention. >>>>>>>
actually specified CANNOT BE VIOLATED.
Of course it can. In fact HHH does violate that. DDD specifies a
halting
behaviour but HHH reports that DDD specifies a non-halting behaviour. >>>>>> That is a violation of that rquirement.
If DDD simulated by HHH stops running for any
reason besides reaching its own "ret" instruction
final halt state THEN DDD HAS NOT HALTED.
Irrelevant. The requirement is that a halt decider predicts whether the >>>> complete execution of the computation described by the input will halt. >>>>
Halting is defined as reaching a final state and
terminating normally.
So, according to this definition, every simulator that aborts after
one instruction is correct to report a non-halting program.
int main()
{
DDD(); // The HHH that DDD calls cannot
} // see the behavior of its caller
*That is incorrect*
A termination analyzer must report on the basis
of the behavior that its input specifies and does
not give a rat's ass about the behavior of its caller.
The caller is not of any interest. The analyser must report on the
input. In this case the anaylzer is given a pointer to memory as
input. This contains the code of DDD. That code has addresses, among
others in call instructions, that gives the analyser access to other
parts of the memory. In this way the analyser should analyse the whole
program, including the code that aborts and halt. If done correctly,
it will see that the input specifies a halting program.
If the input specifies a halting program, such as in this case, this
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
It is a tautology that every input to a simulating
termination analyzer would never stop running unless
aborted specifies a non-terminating sequence of
configurations.
is a vacuous statement. It does not need an abort, because the input
already specifies an abort, which makes the simulation halt, if done
correctly.
You continue to act as if when you are starving
hungry that the fact you won't be hungry after
you have eaten means that you never have to eat.
The actual input is halting, the non-halting input is only in
your dreams. There is no need to halt artificially a halting program.
On 29/05/2025 08:59, Mikko wrote:
The usual meaning of halting is reaching a state where the
computation cannot be computed.
So if the computation /can/ be computed and /has/ been computed, you
don't halt?
Surely that can't be what you meant to say?
On 29/05/2025 16:27, Fred. Zwarts wrote:
The actual input is halting, the non-halting input is only in your
dreams. There is no need to halt artificially a halting program.
Doesn't that rather depend on how long it will take to halt? After all,
your user wants a report, and he might not have all day.
On 5/28/2025 2:43 AM, Mikko wrote:
On 2025-05-27 15:48:14 +0000, olcott said:
On 5/27/2025 3:37 AM, Mikko wrote:
On 2025-05-26 15:57:11 +0000, olcott said:No you don't. All that you need to do is simply imagine
On 5/26/2025 3:46 AM, Mikko wrote:
On 2025-05-25 14:53:06 +0000, olcott said:
On 5/25/2025 4:14 AM, Mikko wrote:
On 2025-05-24 15:18:57 +0000, olcott said:
On 5/24/2025 2:47 AM, Mikko wrote:
On 2025-05-23 02:47:40 +0000, olcott changed the subject to >>>>>>>>>>> How do computations actually work?
Each computation works differently. It does not matter how it works as
long as there are instructions that fully specify how that computation
shall be performed.
All termination analyzers are required to report on the
behavior that their input finite string specifies.
To report correctly. Though the input string to a termination analyzer >>>>>>>> usially is incomlete: the input string usually specifies different >>>>>>>> behavours depending on the input that is not shown to the termination >>>>>>>> analyzer, and the analyzer's report must cover all of them.
A partial termination analyzer may fail to report but is not allowed >>>>>>>> to report incorrectly.
void DDD()
{
HHH(DDD);
return;
}
DDD simulated by HHH cannot possibly reach its
"return" statement final halt state, only liars
will disagree.
Again a straw man deception. Where reasonable people disgraee is the >>>>>> relevance of that claim. The behavour specified by DDD does reach the >>>>>> final return from DDD. Whether HHH can simulate that part of the
behaviour is irrelevant. Even without the simjlation HHH decides
correctly if and only if it determines and reports that DDD halts.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
In order to determine that you need a program that simulates DDD and all >>>> functios DDD calls and detects and counts and reports emulation levels. >>>
that HHH is an x86 emulator capable of emulating itself
emulating DDD. // *This is fully operational code*
Well, you needn't if you have a good substitution. But imagination is
not a good substitution of real work with a real tool.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
has an HHH that does simulate itself simulating DDD.
On 2025-05-29 16:41:26 +0000, Richard Heathfield said:
On 29/05/2025 16:27, Fred. Zwarts wrote:
The actual input is halting, the non-halting input is only in
your dreams. There is no need to halt artificially a halting
program.
Doesn't that rather depend on how long it will take to halt?
After all, your user wants a report, and he might not have all
day.
If the user can't wait until the report is delivered then he
must find out what to do without the report.
On 5/30/2025 2:56 AM, Mikko wrote:
On 2025-05-28 14:33:56 +0000, olcott said:
On 5/28/2025 2:43 AM, Mikko wrote:
On 2025-05-27 15:48:14 +0000, olcott said:
On 5/27/2025 3:37 AM, Mikko wrote:
On 2025-05-26 15:57:11 +0000, olcott said:
On 5/26/2025 3:46 AM, Mikko wrote:
On 2025-05-25 14:53:06 +0000, olcott said:_DDD()
On 5/25/2025 4:14 AM, Mikko wrote:
On 2025-05-24 15:18:57 +0000, olcott said:
On 5/24/2025 2:47 AM, Mikko wrote:
On 2025-05-23 02:47:40 +0000, olcott changed the subject to >>>>>>>>>>>>> How do computations actually work?
Each computation works differently. It does not matter how >>>>>>>>>>>> it works as
long as there are instructions that fully specify how that >>>>>>>>>>>> computation
shall be performed.
All termination analyzers are required to report on the
behavior that their input finite string specifies.
To report correctly. Though the input string to a termination >>>>>>>>>> analyzer
usially is incomlete: the input string usually specifies
different
behavours depending on the input that is not shown to the
termination
analyzer, and the analyzer's report must cover all of them. >>>>>>>>>>
A partial termination analyzer may fail to report but is not >>>>>>>>>> allowed
to report incorrectly.
void DDD()
{
HHH(DDD);
return;
}
DDD simulated by HHH cannot possibly reach its
"return" statement final halt state, only liars
will disagree.
Again a straw man deception. Where reasonable people disgraee is >>>>>>>> the
relevance of that claim. The behavour specified by DDD does
reach the
final return from DDD. Whether HHH can simulate that part of the >>>>>>>> behaviour is irrelevant. Even without the simjlation HHH decides >>>>>>>> correctly if and only if it determines and reports that DDD halts. >>>>>>>
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
In order to determine that you need a program that simulates DDD
and all
functios DDD calls and detects and counts and reports emulation
levels.
No you don't. All that you need to do is simply imagine
that HHH is an x86 emulator capable of emulating itself
emulating DDD. // *This is fully operational code*
Well, you needn't if you have a good substitution. But imagination is
not a good substitution of real work with a real tool.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
has an HHH that does simulate itself simulating DDD.
Nothing behind that pointer refutes my claim that it is not sufficent
to imagine.
When DDD is correctly emulated by HHH the first four
instructions of DDD are emulated. When HHH(DDD) is
called from DDD then HHH emulates itself emulating DDD.
No matter how many times HHH emulates itself emulating
DDD the emulated DDD cannot possibly reach its "ret"
instruction final halt state. This proves that DDD
emulated by HHH is non-halting.
On 5/30/2025 2:56 AM, Mikko wrote:
On 2025-05-28 14:33:56 +0000, olcott said:
On 5/28/2025 2:43 AM, Mikko wrote:
On 2025-05-27 15:48:14 +0000, olcott said:
On 5/27/2025 3:37 AM, Mikko wrote:
On 2025-05-26 15:57:11 +0000, olcott said:No you don't. All that you need to do is simply imagine
On 5/26/2025 3:46 AM, Mikko wrote:
On 2025-05-25 14:53:06 +0000, olcott said:_DDD()
On 5/25/2025 4:14 AM, Mikko wrote:
On 2025-05-24 15:18:57 +0000, olcott said:
On 5/24/2025 2:47 AM, Mikko wrote:
On 2025-05-23 02:47:40 +0000, olcott changed the subject to >>>>>>>>>>>>> How do computations actually work?
Each computation works differently. It does not matter how it works as
long as there are instructions that fully specify how that computation
shall be performed.
All termination analyzers are required to report on the
behavior that their input finite string specifies.
To report correctly. Though the input string to a termination analyzer
usially is incomlete: the input string usually specifies different >>>>>>>>>> behavours depending on the input that is not shown to the termination
analyzer, and the analyzer's report must cover all of them. >>>>>>>>>>
A partial termination analyzer may fail to report but is not allowed >>>>>>>>>> to report incorrectly.
void DDD()
{
HHH(DDD);
return;
}
DDD simulated by HHH cannot possibly reach its
"return" statement final halt state, only liars
will disagree.
Again a straw man deception. Where reasonable people disgraee is the >>>>>>>> relevance of that claim. The behavour specified by DDD does reach the >>>>>>>> final return from DDD. Whether HHH can simulate that part of the >>>>>>>> behaviour is irrelevant. Even without the simjlation HHH decides >>>>>>>> correctly if and only if it determines and reports that DDD halts. >>>>>>>
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
In order to determine that you need a program that simulates DDD and all >>>>>> functios DDD calls and detects and counts and reports emulation levels. >>>>>
that HHH is an x86 emulator capable of emulating itself
emulating DDD. // *This is fully operational code*
Well, you needn't if you have a good substitution. But imagination is
not a good substitution of real work with a real tool.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
has an HHH that does simulate itself simulating DDD.
Nothing behind that pointer refutes my claim that it is not sufficent
to imagine.
When DDD is correctly emulated by HHH the first four
instructions of DDD are emulated. When HHH(DDD) is
called from DDD then HHH emulates itself emulating DDD.
No matter how many times HHH emulates itself emulating
DDD the emulated DDD cannot possibly reach its "ret"
instruction final halt state. This proves that DDD
emulated by HHH is non-halting.
On 5/30/2025 4:05 AM, Richard Heathfield wrote:
On 30/05/2025 08:47, Mikko wrote:
On 2025-05-29 16:41:26 +0000, Richard Heathfield said:
On 29/05/2025 16:27, Fred. Zwarts wrote:
The actual input is halting, the non-halting input is only in your
dreams. There is no need to halt artificially a halting program.
Doesn't that rather depend on how long it will take to halt? After
all, your user wants a report, and he might not have all day.
If the user can't wait until the report is delivered then he
must find out what to do without the report.
That's one option. Or he could use a better termination analyst, one
that doesn't suffer from the fatal flaw inherent in simulation.
Unfortunately, he then runs up against the /other/ fatal flaw, which
is that what he wants can't be done.
The fact that DDD correctly emulated by HHH cannot
possibly stop running unless aborted and cannot
possibly reach its own "ret" instruction final halt
state conclusively proves that the input to HHH(DDD)
specifies a non-halting sequence of configurations.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 512 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 90:48:34 |
| Calls: | 10,018 |
| Calls today: | 1 |
| Files: | 13,849 |
| D/L today: |
1 files (9K bytes) |
| Messages: | 6,365,854 |