This reframing dissolves the paradox
by making the Halting Problem itself an ill-posed question.
On Sun, 11 May 2025 15:44:44 +0100, Richard Heathfield wrote:
but there's nothing self-contradictory or self-referential orparadoxical about the question.
That is simply untrue.
On Sun, 11 May 2025 16:25:14 +0100, Richard Heathfield wrote:
For a question to be semantically incorrect, it takes more than just you
and your allies to be unhappy with it.
For a question to be semantically correct, it takes more than just you and your allies to be happy with it.
Yes and that can be applied to creating a formal system
that comprises the set of all knowledge that can be
expressed in language. In this case Unprovable(x) means
~Knowledge(x). Undecidability cannot possibly occur.
The directly executed DD() simply halts because
HHH has stopped the infinite recursion that it
specifies on its second recursive call.
DD emulated by HHH according to the rules of the
x86 language cannot possibly halt. Because all deciders
are required to report on what their finite string input
specifies HHH must reject DD as non-halting.
On 5/11/2025 10:34 AM, Mr Flibble wrote:
On Sun, 11 May 2025 16:25:14 +0100, Richard Heathfield wrote:
For a question to be semantically incorrect, it takes more
than just you
and your allies to be unhappy with it.
For a question to be semantically correct, it takes more than
just you and
your allies to be happy with it.
Your turn, mate.
/Flibble
For a polar yes/no question to be proven incorrect
only requires that both yes and no are the wrong answer.
it is impossible to obtain a halting result
On 5/11/2025 11:54 AM, dbush wrote:
On 5/11/2025 12:49 PM, olcott wrote:
The category error is actually the fact that everyone
here expects a termination analyzer to report on behavior
other than the behavior that its input finite string
actually specifies.
That's because it's whether or not the algorithm described by
the input halts when executed directly.
No one cares what "the behavior that its input finite string
specifies" because that's not what we asked about.
int sum(int x, int y) { return x + y ; }
when you ask about the sum of 5 + 7 using sum(3,2)
you are asking the wrong question.
HHH reports on the behavior that DDD specifies.
sum reports on the sum that its inputs specify.
The truth is it neither halts nor doesn't halt as the question being asked
is ill-formed.
On Sun, 11 May 2025 18:15:47 +0100, Richard Heathfield wrote:
On 11/05/2025 17:59, Mr Flibble wrote:
it is impossible to obtain a halting result
That sure looks like a concession that it's impossible to devise an
algorithm that will produce a halting result.
Well done. We got you there in the end.
No.
The reason why it is impossible
to obtain a halting result for
pathological input is not the reason proposed by Turing (i.e. self- referential diagonalization),
it is impossible to obtain a halting result
for pathological input because the self-referential conflation of decidermore blah blah blah yeah yeah
and input is a category error that prevents us from performing diagonalization.
On Sun, 11 May 2025 18:26:46 +0100, Richard Heathfield wrote:
On 11/05/2025 18:15, Mr Flibble wrote:
The truth is it neither halts nor doesn't halt as the question being
asked is ill-formed.
So it's stopped running, but it's started hopping?
Your answer is bizarre, but it makes a lot more sense when we realise
that you are desperately trying to avoid saying that it's undecidable.
It is undecidable
but not for the reason given by Turing.
On 5/11/2025 1:54 PM, olcott wrote:
On 5/11/2025 12:49 PM, dbush wrote:
On 5/11/2025 1:44 PM, olcott wrote:
On 5/11/2025 12:34 PM, dbush wrote:
On 5/11/2025 1:14 PM, olcott wrote:
On 5/11/2025 11:54 AM, dbush wrote:
On 5/11/2025 12:49 PM, olcott wrote:
The category error is actually the fact that everyone
here expects a termination analyzer to report on behavior
other than the behavior that its input finite string
actually specifies.
That's because it's whether or not the algorithm described
by the input halts when executed directly.
No one cares what "the behavior that its input finite
string specifies" because that's not what we asked about.
int sum(int x, int y) { return x + y ; }
when you ask about the sum of 5 + 7 using sum(3,2)
you are asking the wrong question.
HHH reports on the behavior that DDD specifies.
sum reports on the sum that its inputs specify.
Category error. (2,3) is not (5,7), but (DDD) is (DDD).
DDD correctly emulated by HHH SPECIFIES RECURSIVE EMULATION
DDD correctly emulated by HHH1 DOES NOT SPECIFY RECURSIVE
EMULATION
What DDD "specifies" is irrelevent. What matters is what
algorithm is described by DDD,
Specifies means provides every single step
of the entire execution trace.
Describes means to mention some details.
We could "describe" DDD by saying that DDD
has the name DDD.
False. By definition, a description contains all information
necessary to exactly replicate what was described.
On Sun, 11 May 2025 15:44:44 +0100, Richard Heathfield wrote:
On 11/05/2025 14:21, Mr Flibble wrote:
This reframing dissolves the paradox by making the Halting Problem
itself an ill-posed question.
"P is a syntactically correct program in some well-defined
Turing-complete language. Does P stop when it is applied to this data
X?" is a meaningful and well-formed question. It's not a Carrollian
question like Olcott's "what time is it, yes or no?" It has a sensible
answer. Either P stops for X, or it doesn't.
It's a question that can in many (but not all) cases be answered quickly
and easily enough (and correctly) by humans, often requiring no more
than a brief glimpse. (I say 'not all' only because it is not beyond the
wit of mankind to trump up extraordinarily complicated and deliberately
obfuscated code that might easily defeat a programmer's casual glance.)
Some simple examples in K&R C:
main(){}
main(){for(;;);}
main(){puts("Hello");}
#include <stdio.h>
main(){long c=0;int ch; while((ch = getchar()) !=
EOF)++c;printf("%ld\n", c);} /* input: the complete works of Shakespeare
*/
Any competent C programmer can solve these at a glance - Halts, Loops,
Halts, Halts, in that order - so why shouldn't a programmer be able to?
The Halting Problem asks a more complicated question. ``Is it possible
to write a program that answers the above question for arbitrary P and
arbitrary X?"
Again, the question is meaningful and well-formed. It's syntactically
and grammatically adequate, and anyone claiming not to know what it
means is laying themselves open to a charge of disingenuousness. The
only difficult part is the answer, but there's nothing
self-contradictory or self-referential or paradoxical about the
question.
It is insufficient for the question to be syntactically correct, it needs
to be SEMANTICALLY correct too.
/Flibble
On Sun, 11 May 2025 16:25:14 +0100, Richard Heathfield wrote:
For a question to be semantically incorrect, it takes more than just you
and your allies to be unhappy with it.
For a question to be semantically correct, it takes more than just you and your allies to be happy with it.
Your turn, mate.
/Flibble
Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in
the Halting Problem ===========================================================================================
Summary
-------
Flibble argues that the Halting Problem's undecidability proof is built on
a category (type) error: it assumes a program and its own representation
(as a finite string) are interchangeable. This assumption fails under simulating deciders, revealing a type distinction through behavioral divergence. As such, all deciders must respect this boundary, and diagonalization becomes ill-formed. This reframing dissolves the paradox
by making the Halting Problem itself an ill-posed question.
1. Operational Evidence of Type Distinction -------------------------------------------
- When a program (e.g., `DD()`) is passed to a simulating halt decider (`HHH`), it leads to infinite recursion.
- This behavior differs from direct execution (e.g., a crash due to a
stack overflow).
- This divergence shows that the program (as code) and its representation
(as data) are operationally distinct.
- Therefore, treating them as the same "type" (as Turing's proof does)
leads to inconsistency.
2. Generalization to All Deciders
---------------------------------
- If simulation reveals this type mismatch, then no valid decider can rely
on conflating program and representation.
- Diagonalization (e.g., defining D(x) = if H(x,x) then loop else halt) necessarily crosses the type boundary.
- The contradiction in the Halting Problem arises from this type error,
not from inherent undecidability.
- Hence, the Halting Problem is ill-defined for self-referential input.
3. Comparisons to Other Formal Systems
--------------------------------------
- In type-theoretic systems (like Coq or Agda), such self-reference is disallowed:
- Programs must be well-typed.
- Self-referential constructs like `H(x, x)` are unrepresentable if they would lead to paradox.
- In category theory, morphisms must respect domain/codomain boundaries:
- Reflexive constructions require stratification to avoid logical inconsistency.
4. Conclusion
-------------
- The Halting Problem depends on self-reference and diagonalization.
- If these constructs are blocked due to type/category errors, the proof breaks down.
- Thus, the Halting Problem isn’t undecidable—it’s malformed when it crosses type boundaries.
- This is not a refutation of Turing, but a reformulation of the problem under more disciplined typing rules.
This model mirrors how Russell’s Paradox was avoided in modern logic: not by solving the contradiction, but by redefining the terms that made the contradiction possible.
On Sun, 11 May 2025 16:47:09 +0100, Richard Heathfield wrote:
On 11/05/2025 16:34, Mr Flibble wrote:
On Sun, 11 May 2025 16:25:14 +0100, Richard Heathfield wrote:
For a question to be semantically incorrect, it takes more than just
you and your allies to be unhappy with it.
For a question to be semantically correct, it takes more than just you
and your allies to be happy with it.
Indeed. It has to have meaning. It does. That meaning has to be
understood by sufficiently intelligent people. It is.
You don't like the question. I get that. I don't know /why/ you don't
like it, because all your explanations to date have been complete
expletive deleted. For a Usenet article to be semantically correct, it
helps if your readers can understand what the <exp. del.> you're talking
about.
What I get from your stand is that you agree with olcott that a
'pathological' input halts... no, never halts... well, you can't decide
between you, but you're agreed that it's definitely decidable, right?
Re-read the OP for my answer:
Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in
the Halting Problem ===========================================================================================
Summary
-------
Flibble argues that the Halting Problem's undecidability proof is built on
a category (type) error: it assumes a program and its own representation
(as a finite string) are interchangeable. This assumption fails under simulating deciders, revealing a type distinction through behavioral divergence. As such, all deciders must respect this boundary, and diagonalization becomes ill-formed. This reframing dissolves the paradox
by making the Halting Problem itself an ill-posed question.
1. Operational Evidence of Type Distinction -------------------------------------------
- When a program (e.g., `DD()`) is passed to a simulating halt decider (`HHH`), it leads to infinite recursion.
- This behavior differs from direct execution (e.g., a crash due to a
stack overflow).
- This divergence shows that the program (as code) and its representation
(as data) are operationally distinct.
- Therefore, treating them as the same "type" (as Turing's proof does)
leads to inconsistency.
2. Generalization to All Deciders
---------------------------------
- If simulation reveals this type mismatch, then no valid decider can rely
on conflating program and representation.
- Diagonalization (e.g., defining D(x) = if H(x,x) then loop else halt) necessarily crosses the type boundary.
- The contradiction in the Halting Problem arises from this type error,
not from inherent undecidability.
- Hence, the Halting Problem is ill-defined for self-referential input.
3. Comparisons to Other Formal Systems
--------------------------------------
- In type-theoretic systems (like Coq or Agda), such self-reference is disallowed:
- Programs must be well-typed.
- Self-referential constructs like `H(x, x)` are unrepresentable if they would lead to paradox.
- In category theory, morphisms must respect domain/codomain boundaries:
- Reflexive constructions require stratification to avoid logical inconsistency.
4. Conclusion
-------------
- The Halting Problem depends on self-reference and diagonalization.
- If these constructs are blocked due to type/category errors, the proof breaks down.
- Thus, the Halting Problem isn’t undecidable—it’s malformed when it crosses type boundaries.
- This is not a refutation of Turing, but a reformulation of the problem under more disciplined typing rules.
This model mirrors how Russell’s Paradox was avoided in modern logic: not by solving the contradiction, but by redefining the terms that made the contradiction possible.
On 5/11/2025 10:49 AM, Mr Flibble wrote:
On Sun, 11 May 2025 16:47:09 +0100, Richard Heathfield wrote:
On 11/05/2025 16:34, Mr Flibble wrote:
On Sun, 11 May 2025 16:25:14 +0100, Richard Heathfield wrote:
For a question to be semantically incorrect, it takes more than just >>>>> you and your allies to be unhappy with it.
For a question to be semantically correct, it takes more than just you >>>> and your allies to be happy with it.
Indeed. It has to have meaning. It does. That meaning has to be
understood by sufficiently intelligent people. It is.
You don't like the question. I get that. I don't know /why/ you don't
like it, because all your explanations to date have been complete
expletive deleted. For a Usenet article to be semantically correct, it
helps if your readers can understand what the <exp. del.> you're talking >>> about.
What I get from your stand is that you agree with olcott that a
'pathological' input halts... no, never halts... well, you can't decide
between you, but you're agreed that it's definitely decidable, right?
Re-read the OP for my answer:
Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in
the Halting Problem
===========================================================================================
Summary
-------
Flibble argues that the Halting Problem's undecidability proof is
built on
a category (type) error: it assumes a program and its own representation
(as a finite string) are interchangeable. This assumption fails under
simulating deciders, revealing a type distinction through behavioral
divergence. As such, all deciders must respect this boundary, and
diagonalization becomes ill-formed. This reframing dissolves the paradox
by making the Halting Problem itself an ill-posed question.
1. Operational Evidence of Type Distinction
-------------------------------------------
- When a program (e.g., `DD()`) is passed to a simulating halt decider
(`HHH`), it leads to infinite recursion.
- This behavior differs from direct execution (e.g., a crash due to a
stack overflow).
The directly executed DD() simply halts because
HHH has stopped the infinite recursion that it
specifies on its second recursive call.
DD emulated by HHH according to the rules of the
x86 language cannot possibly halt. Because all deciders
are required to report on what their finite string input
specifies HHH must reject DD as non-halting.
On Sun, 11 May 2025 15:44:44 +0100, Richard Heathfield wrote:
but there's nothing self-contradictory or self-referential orparadoxical about the question.
That is simply untrue.
/Flibble
On Sun, 11 May 2025 15:55:34 -0400, Richard Damon wrote:
On 5/11/25 11:49 AM, Mr Flibble wrote:
On Sun, 11 May 2025 16:47:09 +0100, Richard Heathfield wrote:
On 11/05/2025 16:34, Mr Flibble wrote:
On Sun, 11 May 2025 16:25:14 +0100, Richard Heathfield wrote:
For a question to be semantically incorrect, it takes more than just >>>>>> you and your allies to be unhappy with it.
For a question to be semantically correct, it takes more than just
you and your allies to be happy with it.
Indeed. It has to have meaning. It does. That meaning has to be
understood by sufficiently intelligent people. It is.
You don't like the question. I get that. I don't know /why/ you don't
like it, because all your explanations to date have been complete
expletive deleted. For a Usenet article to be semantically correct, it >>>> helps if your readers can understand what the <exp. del.> you're
talking about.
What I get from your stand is that you agree with olcott that a
'pathological' input halts... no, never halts... well, you can't
decide between you, but you're agreed that it's definitely decidable,
right?
Re-read the OP for my answer:
Which is full of errors as I have pointed out.
Sorry mate but you have missed the boat as I have moved on: I am happy
with my final solution; I glanced over all your responses in this thread
and they are all invalid.
In summary:
* pathological input is undecidable but not for the reason given in the extant halting problem proofs;
* pathological input should be removed from the set of programs that can
be analysed by a decider for further research in this area to be useful rather than just a circle jerk.
/Flibble
Mr Flibble <flibble@red-dwarf.jmc.corp> writes:
On Sun, 11 May 2025 18:15:47 +0100, Richard Heathfield wrote:
On 11/05/2025 17:59, Mr Flibble wrote:
it is impossible to obtain a halting result
That sure looks like a concession that it's impossible to devise an
algorithm that will produce a halting result.
Well done. We got you there in the end.
No. The reason why it is impossible to obtain a halting result for
pathological input is not the reason proposed by Turing (i.e. self-
referential diagonalization), it is impossible to obtain a halting result
for pathological input because the self-referential conflation of decider
and input is a category error that prevents us from performing
diagonalization.
Is it possible to determine whether a given input is "pathological" or not?
To usefully advance research in this area pathological input needs to be
excluded from the set of programs that can be analysed by a decider.
Can this exclusion be performed reliably and consistently?
On 5/11/2025 4:42 PM, Mr Flibble wrote:
On Sun, 11 May 2025 15:55:34 -0400, Richard Damon wrote:
On 5/11/25 11:49 AM, Mr Flibble wrote:
On Sun, 11 May 2025 16:47:09 +0100, Richard Heathfield wrote:
On 11/05/2025 16:34, Mr Flibble wrote:
On Sun, 11 May 2025 16:25:14 +0100, Richard Heathfield wrote:
For a question to be semantically incorrect, it takes more than just >>>>>>> you and your allies to be unhappy with it.
For a question to be semantically correct, it takes more than just >>>>>> you and your allies to be happy with it.
Indeed. It has to have meaning. It does. That meaning has to be
understood by sufficiently intelligent people. It is.
You don't like the question. I get that. I don't know /why/ you don't >>>>> like it, because all your explanations to date have been complete
expletive deleted. For a Usenet article to be semantically correct, it >>>>> helps if your readers can understand what the <exp. del.> you're
talking about.
What I get from your stand is that you agree with olcott that a
'pathological' input halts... no, never halts... well, you can't
decide between you, but you're agreed that it's definitely decidable, >>>>> right?
Re-read the OP for my answer:
Which is full of errors as I have pointed out.
Sorry mate but you have missed the boat as I have moved on: I am happy
with my final solution; I glanced over all your responses in this thread
and they are all invalid.
In summary:
* pathological input is undecidable but not for the reason given in the
extant halting problem proofs;
* pathological input should be removed from the set of programs that can
be analysed by a decider for further research in this area to be useful
rather than just a circle jerk.
/Flibble
I use similar reasoning for my rebuttal of
the Tarski Undefinability theorem.
The formalized version of "This sentence is not true"
is rejected as not having any truth value.
On 5/11/2025 6:05 PM, Keith Thompson wrote:
Mr Flibble <flibble@red-dwarf.jmc.corp> writes:
On Sun, 11 May 2025 18:15:47 +0100, Richard Heathfield wrote:
On 11/05/2025 17:59, Mr Flibble wrote:
it is impossible to obtain a halting result
That sure looks like a concession that it's impossible to devise an
algorithm that will produce a halting result.
Well done. We got you there in the end.
No. The reason why it is impossible to obtain a halting result for
pathological input is not the reason proposed by Turing (i.e. self-
referential diagonalization), it is impossible to obtain a halting
result
for pathological input because the self-referential conflation of
decider
and input is a category error that prevents us from performing
diagonalization.
Is it possible to determine whether a given input is "pathological" or
not?
To usefully advance research in this area pathological input needs to be >>> excluded from the set of programs that can be analysed by a decider.
Can this exclusion be performed reliably and consistently?
That is a good question. The answer is definitely
yes. When HHH emulates DDD it only needs to see
that DDD is calling itself with no conditional branch
instructions inbetween.
Whether a function computed by a Turing machine can
do this is a different question.
On 5/11/25 5:42 PM, Mr Flibble wrote:
I am happy with my final solution; I glanced over all your
responses in this thread and they are all invalid.
In other words, you are admtting to being happy to be in error.
On 5/11/2025 6:45 PM, Richard Damon wrote:
On 5/11/25 7:14 PM, olcott wrote:
On 5/11/2025 6:05 PM, Keith Thompson wrote:
Mr Flibble <flibble@red-dwarf.jmc.corp> writes:
On Sun, 11 May 2025 18:15:47 +0100, Richard Heathfield wrote:
On 11/05/2025 17:59, Mr Flibble wrote:
it is impossible to obtain a halting result
That sure looks like a concession that it's impossible to devise an >>>>>> algorithm that will produce a halting result.
Well done. We got you there in the end.
No. The reason why it is impossible to obtain a halting result for
pathological input is not the reason proposed by Turing (i.e. self-
referential diagonalization), it is impossible to obtain a halting
result
for pathological input because the self-referential conflation of
decider
and input is a category error that prevents us from performing
diagonalization.
Is it possible to determine whether a given input is "pathological"
or not?
To usefully advance research in this area pathological input needs
to be
excluded from the set of programs that can be analysed by a decider.
Can this exclusion be performed reliably and consistently?
That is a good question. The answer is definitely
yes. When HHH emulates DDD it only needs to see
that DDD is calling itself with no conditional branch
instructions inbetween.
Whether a function computed by a Turing machine can
do this is a different question.
So, try to do it.
No need to. DDD emulated by HHH according to the
rules of the computational language that DD is
encoded within already proves that the HP
"impossible" input specifies a non-halting
sequence of configurations.
This by itself is much more progress than anyone
else has ever made on the halting problem.
To the best of my recollection
Mike has already agreed that the outermost HHH
can dig into the details of all of the levels
of recursive simulation to get the details that
it currently uses. All of these details are
merely data to this outermost HHH.
This is analogous to a master UTM examining
all of its own tape, even those portions that
are allocated to slave UTMs.
No one here is using any actual reasoning
in their rebuttals of my work.
They rely
on dogma, misdirection, deflection and the
strawman error.
The last three methods are dishonest.
On 5/11/2025 8:07 PM, Richard Heathfield wrote:
On 12/05/2025 00:19, Richard Damon wrote:
On 5/11/25 5:42 PM, Mr Flibble wrote:
<snip>
I am happy with my final solution; I glanced over all your
responses in this thread and they are all invalid.
In other words, you are admtting to being happy to be in error.
He has form for placing a finger in each ear and yelling "I'm right
I'm right I'm right you're all wrong!"
There's no talking to 2-year-olds.
No one here is using any actual reasoning
in their rebuttals of my work. They rely
on dogma, misdirection, deflection and the
strawman error.
The last three methods are dishonest.
On 5/11/2025 8:34 PM, Richard Heathfield wrote:
On 12/05/2025 02:12, olcott wrote:
<snip>
No one here is using any actual reasoning
in their rebuttals of my work.
I have already shown several places where your 'work' violates
the rules of its implementation's language standard,
My compiler disagrees so I can't fix that.
Halt7.c must be compiled with the Microsoft
compiler to get the correct object file type.
On 5/11/2025 8:37 PM, Richard Damon wrote:
On 5/11/25 9:12 PM, olcott wrote:
On 5/11/2025 8:07 PM, Richard Heathfield wrote:
On 12/05/2025 00:19, Richard Damon wrote:
On 5/11/25 5:42 PM, Mr Flibble wrote:
<snip>
I am happy with my final solution; I glanced over all your
responses in this thread and they are all invalid.
In other words, you are admtting to being happy to be in error.
He has form for placing a finger in each ear and yelling "I'm
right I'm right I'm right you're all wrong!"
There's no talking to 2-year-olds.
No one here is using any actual reasoning
in their rebuttals of my work. They rely
on dogma, misdirection, deflection and the
strawman error.
The last three methods are dishonest.
No, they are responding with rules and definitions from the
system in question,
A syntax error reporting by one compiler
and considered
irrelevant by another compiler
provides zero evidence
that DDD correctly emulated by some HHH halts.
Because you don't give a rat's ass for the actual
truth
you ignore the actual rebuttal requirements.
C code is not as 100% exactingly precise as x86 code.
Richard Heathfield <rjh@cpax.org.uk> writes:
[...]
ALL C compilers are required to diagnose ALL syntax errors and ALL
constraint violations.
Yes, all conforming C compilers are required to do that. (Well,
strictly speaking they're only required to issue at least one diagnostic
for any translation unit that violates a syntax rule or constraint.)
[...]
In my experience, Microsoft's C compiler - although not perfect - is
pretty good at following conformance rules. I'd be surprised to learn
from a competent source that it misses a syntax error.
I wouldn't, since few if any C compilers are conforming by default.
I've just tried 4 different C compilers (gcc, clang, and tcc
on Ubuntu, MS Visual Studio 2022 on Windows), and none of them
diagnosed a stray semicolon at file scope *by default*. gcc and
clang can be persuaded to diagnose it. tcc, as far as I can tell,
cannot; I don't believe it claims to be fully conforming in any mode.
I wasn't able to get MSVS to diagnose it, but there could easily
be an option that I'm missing.
If I wanted to prove something in mathematical logic using C code as
a vehicle, I personally would try to use fully standard-conforming C.
I *might* consider using a more lax C-like language, such as the
language accepted by some C compiler in its default mode -- but I'd
need a good reason to do that, and I'd want a rigorous definition
of anything I use that differs from standard C.
It's possible that olcott's C-like code has well defined behavior
in the implementation he's using. If so, I'm not sure there's any fundamental reason to use something close to C rather than using C
itself in an attempted refutation of some well known mathematical
proof. (I wouldn't expect either C or something C-like to be a
good vehicle for such a proof. I don't think C is defined rigorously
enough to be useful for such a task, and any C-like language is even
less so.)
olcott will likely use this to claim that I support his views.
He will be wrong.
Richard Heathfield <rjh@cpax.org.uk> writes:
On 12/05/2025 04:11, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
[...]
ALL C compilers are required to diagnose ALL syntax errors and ALLYes, all conforming C compilers are required to do that. (Well,
constraint violations.
strictly speaking they're only required to issue at least one diagnostic >>> for any translation unit that violates a syntax rule or constraint.)
I was unintentionally ambiguous, for which I apologise.
The point I sought to make is that there is no syntax error (or
constraint violation) so trivial that a compiler is given licence not
to issue a diagnostic it if it has no other reason so to do.
That is, they are all capable of ticking the box that says 'must issue
at least one diagnostic'.
[...]
In my experience, Microsoft's C compiler - although not perfect - isI wouldn't, since few if any C compilers are conforming by default.
pretty good at following conformance rules. I'd be surprised to learn
from a competent source that it misses a syntax error.
I was talking about conforming mode, which IIRC (it's been a while) is
invoked by -W4 (a warning level that I habitually used in the days
when I still used Microsoft software).
I've just tried 4 different C compilers (gcc, clang, and tcc
on Ubuntu, MS Visual Studio 2022 on Windows), and none of them
diagnosed a stray semicolon at file scope *by default*. gcc and
clang can be persuaded to diagnose it. tcc, as far as I can tell,
cannot; I don't believe it claims to be fully conforming in any mode.
I wasn't able to get MSVS to diagnose it, but there could easily
be an option that I'm missing.
Could you crank MSVS up to -W4 (or whatever the max is these days) and
try again? I hate to impose, but of course it's your own fault for
qualifying as a competent source. ;-)
It's "/W4".
The default appears to be "/W3".
With "/W4", or even "/Wall", it still doesn't diagnose a stray semicolon
at file scope. (I wouldn't expect a warning option to be the
incantation that makes the compiler conform to the standard.)
The "/Za" option
is supposed to disable language extensions,
but it
complains that "'/Za' and '/std:c17' command-line options are
incompatible".
The implementation supports both C and C++. It seems to treat C as a second-class citizen.
(I think, but I'm not sure, that a stray
semicolon at file scope is legal in C++; it's called an
"empty-declaration".)
If it doesn't diagnose at its maximum warning level, then okay, ~I
lose the syntax battle.
I'd say that Microsoft's compiler loses the syntax battle.
On 5/11/2025 9:42 PM, dbush wrote:
On 5/11/2025 10:39 PM, olcott wrote:
On 5/11/2025 9:34 PM, dbush wrote:
On 5/11/2025 10:30 PM, olcott wrote:
On 5/11/2025 9:23 PM, Richard Heathfield wrote:
On 12/05/2025 03:05, olcott wrote:
On 5/11/2025 8:34 PM, Richard Heathfield wrote:
On 12/05/2025 02:12, olcott wrote:
<snip>
No one here is using any actual reasoning
in their rebuttals of my work.
I have already shown several places where your 'work' violates >>>>>>>> the rules of its implementation's language standard,
My compiler disagrees so I can't fix that.
C compilers are obliged to diagnose syntax errors. If they don't,
they're not-quite-C compilers. You need to decide whether you're
writing in C or whether you're not.
_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]
When testing the proof-of-concept not one line
of my code is relevant. The only thing that needs
be determined is the behavior of DDD under some
HHH
Category error. Algorithm DDD isn't fully defined until algorithm
HHH is fully defined.
So yes the code is relevant.
Algorithm HHH is fully defined as an x86 emulator
that emulates one or more steps of DDD according
to the rules of the x86 language.
Which means "some HHH" is a category error. There is only one
algorithm HHH and one algorithm DDD.
*You absolutely refuse to get the gist of anything*
There cannot possibly exist an x86 emulator at machine
address 000015d2 that emulates one or more instructions
of DDD according to the rules of the x86 language such
that the correctly emulated DDD reaches its own "ret"
instruction final halt state.
On 5/11/2025 9:54 PM, dbush wrote:
On 5/11/2025 10:53 PM, olcott wrote:
On 5/11/2025 9:42 PM, dbush wrote:
On 5/11/2025 10:39 PM, olcott wrote:
On 5/11/2025 9:34 PM, dbush wrote:
On 5/11/2025 10:30 PM, olcott wrote:
On 5/11/2025 9:23 PM, Richard Heathfield wrote:
On 12/05/2025 03:05, olcott wrote:
On 5/11/2025 8:34 PM, Richard Heathfield wrote:
On 12/05/2025 02:12, olcott wrote:
<snip>
No one here is using any actual reasoning
in their rebuttals of my work.
I have already shown several places where your 'work' violates >>>>>>>>>> the rules of its implementation's language standard,
My compiler disagrees so I can't fix that.
C compilers are obliged to diagnose syntax errors. If they
don't, they're not-quite-C compilers. You need to decide whether >>>>>>>> you're writing in C or whether you're not.
_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]
When testing the proof-of-concept not one line
of my code is relevant. The only thing that needs
be determined is the behavior of DDD under some
HHH
Category error. Algorithm DDD isn't fully defined until algorithm >>>>>> HHH is fully defined.
So yes the code is relevant.
Algorithm HHH is fully defined as an x86 emulator
that emulates one or more steps of DDD according
to the rules of the x86 language.
Which means "some HHH" is a category error. There is only one
algorithm HHH and one algorithm DDD.
*You absolutely refuse to get the gist of anything*
There cannot possibly exist an x86 emulator at machine
address 000015d2 that emulates one or more instructions
of DDD
Changing the input is not allowed.
I am talking about every element of an infinite set you nitwit.
On 5/12/2025 6:47 AM, Richard Damon wrote:
On 5/11/25 10:30 PM, olcott wrote:
On 5/11/2025 9:23 PM, Richard Heathfield wrote:
On 12/05/2025 03:05, olcott wrote:
On 5/11/2025 8:34 PM, Richard Heathfield wrote:
On 12/05/2025 02:12, olcott wrote:
<snip>
No one here is using any actual reasoning
in their rebuttals of my work.
I have already shown several places where your 'work' violates the >>>>>> rules of its implementation's language standard,
My compiler disagrees so I can't fix that.
C compilers are obliged to diagnose syntax errors. If they don't,
they're not-quite-C compilers. You need to decide whether you're
writing in C or whether you're not.
_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]
When testing the proof-of-concept not one line
of my code is relevant. The only thing that needs
be determined is the behavior of DDD under some
HHH that emulates DDD according to the rules of
the x86 language.
But then HHH must do that, and you HHH that answers doesn't.
Of every x86 emulator at machine address 000015d2
that correctly emulates 1 or more instructions of
DDD none of these correctly emulated DDD instances
ever reaches its own "ret" instruction final halt state.
On 5/12/2025 10:48 AM, dbush wrote:
On 5/12/2025 11:46 AM, olcott wrote:
On 5/12/2025 6:47 AM, Richard Damon wrote:
On 5/11/25 10:30 PM, olcott wrote:
On 5/11/2025 9:23 PM, Richard Heathfield wrote:
On 12/05/2025 03:05, olcott wrote:
On 5/11/2025 8:34 PM, Richard Heathfield wrote:
On 12/05/2025 02:12, olcott wrote:
<snip>
No one here is using any actual reasoning
in their rebuttals of my work.
I have already shown several places where your 'work' violates >>>>>>>> the rules of its implementation's language standard,
My compiler disagrees so I can't fix that.
C compilers are obliged to diagnose syntax errors. If they don't,
they're not-quite-C compilers. You need to decide whether you're
writing in C or whether you're not.
_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]
When testing the proof-of-concept not one line
of my code is relevant. The only thing that needs
be determined is the behavior of DDD under some
HHH that emulates DDD according to the rules of
the x86 language.
But then HHH must do that, and you HHH that answers doesn't.
Of every x86 emulator at machine address 000015d2
that correctly emulates 1 or more instructions of
DDD none of these correctly emulated DDD instances
ever reaches its own "ret" instruction final halt state.
Changing the input is not allowed.
Of the infinite set of HHH/DDD pairs that are
being simultaneously evaluated each DDD has
its own unique HHH thus nothing has changed
for this element of the infinite set.
On 5/11/2025 10:11 PM, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
[...]
ALL C compilers are required to diagnose ALL syntax errors and ALL
constraint violations.
Yes, all conforming C compilers are required to do that. (Well,
strictly speaking they're only required to issue at least one diagnostic
for any translation unit that violates a syntax rule or constraint.)
[...]
In my experience, Microsoft's C compiler - although not perfect - is
pretty good at following conformance rules. I'd be surprised to learn
from a competent source that it misses a syntax error.
I wouldn't, since few if any C compilers are conforming by default.
I've just tried 4 different C compilers (gcc, clang, and tcc
on Ubuntu, MS Visual Studio 2022 on Windows), and none of them
diagnosed a stray semicolon at file scope *by default*. gcc and
clang can be persuaded to diagnose it. tcc, as far as I can tell,
cannot; I don't believe it claims to be fully conforming in any mode.
I wasn't able to get MSVS to diagnose it, but there could easily
be an option that I'm missing.
If I wanted to prove something in mathematical logic using C code as
a vehicle, I personally would try to use fully standard-conforming C.
I *might* consider using a more lax C-like language, such as the
language accepted by some C compiler in its default mode -- but I'd
need a good reason to do that, and I'd want a rigorous definition
of anything I use that differs from standard C.
It's possible that olcott's C-like code has well defined behavior
in the implementation he's using. If so, I'm not sure there's any
fundamental reason to use something close to C rather than using C
itself in an attempted refutation of some well known mathematical
proof. (I wouldn't expect either C or something C-like to be a
good vehicle for such a proof. I don't think C is defined rigorously
enough to be useful for such a task, and any C-like language is even
less so.)
olcott will likely use this to claim that I support his views.
He will be wrong.
[...]
C code is not as 100% exactingly precise as x86 code.
_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]
When one or more steps of DDD are correctly emulated
by any x86 emulator HHH the result is the same as
this code correctly simulated by a C interpreter.
void DDD()
{
HHH(DDD);
return;
}
I have the "return" statement in there because it
marks a final halt state that is never reached.
If a computation stops running for any reason
besides reaching a final halt state comp theory
says that this computation never halted. Thus
DDD emulated by HHH never halts.
People in this forum have been consistently dishonest
about this point for three years.
On 5/12/2025 6:51 AM, Richard Damon wrote:
On 5/11/25 10:09 PM, olcott wrote:
On 5/11/2025 8:37 PM, Richard Damon wrote:
On 5/11/25 9:12 PM, olcott wrote:
On 5/11/2025 8:07 PM, Richard Heathfield wrote:
On 12/05/2025 00:19, Richard Damon wrote:
On 5/11/25 5:42 PM, Mr Flibble wrote:
<snip>
I am happy with my final solution; I glanced over all your
responses in this thread and they are all invalid.
In other words, you are admtting to being happy to be in error.
He has form for placing a finger in each ear and yelling "I'm
right I'm right I'm right you're all wrong!"
There's no talking to 2-year-olds.
No one here is using any actual reasoning
in their rebuttals of my work. They rely
on dogma, misdirection, deflection and the
strawman error.
The last three methods are dishonest.
No, they are responding with rules and definitions from the system
in question,
A syntax error reporting by one compiler and considered
irrelevant by another compiler provides zero evidence
that DDD correctly emulated by some HHH halts.
I wasn't talking about "Syntax Errors".
I was talking about the rules of the field of Computation Theory.
_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]
THE ONLY THING THAT SHOWS THIS IS THE IS THE
COMPLETE SEQUENCE OF EMULATED STEPS WHERE DDD HALTS.
Which is impossble to do as the above is *NOT* a program, as it fails
to have all the code that it uses.
It need not be a program knucklehead.
Termination analyzers often work on C functions.
On 5/12/2025 11:32 AM, Ben Bacarisse wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 11/05/2025 17:29, olcott wrote:
On 5/11/2025 10:34 AM, Mr Flibble wrote:
On Sun, 11 May 2025 16:25:14 +0100, Richard Heathfield wrote:For a polar yes/no question to be proven incorrect
For a question to be semantically incorrect, it takes more than just >>>>>> you
and your allies to be unhappy with it.
For a question to be semantically correct, it takes more than just you >>>>> and
your allies to be happy with it.
Your turn, mate.
/Flibble
only requires that both yes and no are the wrong answer.
Fair enough.
Definition: YNA - a type of answer that has exactly one of exactly two
possible values, either 'yes' xor 'no' - not both, not neither, and not
banana or half-past four.
The two questions I presented upthread, which I'll now label QA and
QB, are
both of type YNA. They are as follows:
QA: "P is a syntactically correct program in some well-defined
Turing-complete language. Does P stop when it is applied to this data
X?"
Sometimes PO accepts this a yes/no question with a correct answer in
every case and sometimes he does not. On those days when he does accept
it, he asserts (quite unambiguously -- I can post a direct quote or a
message ID) that no is sometimes the correct answer even when P(X)
halts.
The Tarski undefinability theorem totally fails when
it is understood that every form of the Liar Paradox
is simply not a truth bearer, thus the Liar Paradox
must be rejected as not an element of any formal
system of mathematical logic.
QB: ``Is it possible to write a program that answers QA for arbitrary
P and
arbitrary X?"
For any P and any X, QA has a correct YNA answer. What that answer is
depends on P and X, but QA(P,X) can correctly answer with one valid YNA
response or the other.
But on some days, PO does /not/ accept that there is a correct yes/no
answer to QA in every case. On those days, he thinks there is a
"pathological input" for which there is no correct answer.
I have dropped my other view that that the halting
problem counter-example input is malformed because
its recursive simulation prevents the "do the opposite"
of whatever its corresponding termination analyzer reports
is unreachable code.
This was a very common problem with students. They so buy into the
assumption "let H be a TM that decides halting" that they think that H'
and H^ (to use Linz's notation) also exist and so there really is a
concrete string of symbols (the encoding of H^ which I write as [H^])
such that H^([H^]) halts if it doesn't and doesn't halt if it does.
Of course, there are no pathological inputs like this because H does not
exist. For every TM, M, the machines M' and M^ do indeed exist, [M^]
really is some finite string of symbols and M^([M^]) either halts or it
does not halt. But because none of the infinite variety of Ms
implements the halting function, there is no paradox or pathological
input anywhere to be seen.
Aside... Forgive me for repeatedly replying to you. It's because I
know you from comp.lang.c and because you are, I think, new to this
thread which has been going on for over 20 years. I think everyone else
here knows the history, but you might not know what PO has said in the
past and, anyway, I think it helps to remind everyone that PO has given
the game away more than once.
All the recent junk using x86 simulations was once very much clearer.
He posted a function:
u32 Halts(u32 P, u32 I)
{
static u32* execution_trace;
slave_state->EIP = P; // Function to invoke
while (!Aborted)
{
u32 EIP = slave_state->EIP; // Instruction to be executed
DebugStep(master_state, slave_state); // Execute this instruction >> PushBack(local_execution_trace_list, EIP);
Aborted = Needs_To_Be_Aborted(execution_trace, (u32)Halts);
}
return 0; // Does not halt
END_OF_CODE: // Input has normally terminated
return 1;
}
and explained that 0 (does not halt) is the correct return for the
classic "confounding input" like so:
"When we comment out the line of Halts() that tests for its need to
abort then H_Hat() remains in infinite recursion, proving that its
abort decision was correct."
All really clear: Halts is correct because it reports on what some other
program would do -- the H_Hat constructed from the modified Halts
function without the like that stops the simulation!
That was way too clear, so we got all more recent guff and, as far as I
know, he no loner ties to justify this ruse quite so explicitly. His
argument is now that the simulation is correct right up until the point
when it isn't (as Mike Terry demonstrated quite explicitly).
Try to show how the "do the opposite" code
is reachable from DD correctly simulated by HHH.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
On 5/11/2025 9:48 AM, Mr Flibble wrote:
On Sun, 11 May 2025 15:44:44 +0100, Richard Heathfield wrote:
On 11/05/2025 14:21, Mr Flibble wrote:
This reframing dissolves the paradox by making the Halting Problem
itself an ill-posed question.
"P is a syntactically correct program in some well-defined
Turing-complete language. Does P stop when it is applied to this data
X?" is a meaningful and well-formed question. It's not a Carrollian
question like Olcott's "what time is it, yes or no?" It has a sensible
answer. Either P stops for X, or it doesn't.
It's a question that can in many (but not all) cases be answered quickly >>> and easily enough (and correctly) by humans, often requiring no more
than a brief glimpse. (I say 'not all' only because it is not beyond the >>> wit of mankind to trump up extraordinarily complicated and deliberately
obfuscated code that might easily defeat a programmer's casual glance.)
Some simple examples in K&R C:
main(){}
main(){for(;;);}
main(){puts("Hello");}
#include <stdio.h>
main(){long c=0;int ch; while((ch = getchar()) !=
EOF)++c;printf("%ld\n", c);} /* input: the complete works of Shakespeare >>> */
Any competent C programmer can solve these at a glance - Halts, Loops,
Halts, Halts, in that order - so why shouldn't a programmer be able to?
The Halting Problem asks a more complicated question. ``Is it possible
to write a program that answers the above question for arbitrary P and
arbitrary X?"
Again, the question is meaningful and well-formed. It's syntactically
and grammatically adequate, and anyone claiming not to know what it
means is laying themselves open to a charge of disingenuousness. The
only difficult part is the answer, but there's nothing
self-contradictory or self-referential or paradoxical about the
question.
It is insufficient for the question to be syntactically correct, it needs
to be SEMANTICALLY correct too.
/Flibble
A very important point.
Prolog detects that the Liar Paradox is semantically
incorrect because it specifies the same infinite
recursion as the Halting Problem proofs.
Unlike formal systems that simply get stuck in
infinite recursion, algorithms are smarter. They
can detect and reject them.
Tarski anchored his whole undefinability theorem
in the nonsense of the Liar Paradox.
On 5/12/2025 3:53 AM, Mikko wrote:
On 2025-05-11 13:21:31 +0000, Mr Flibble said:
Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in >>> the Halting Problem
===========================================================================================
Summary
-------
Flibble argues that the Halting Problem's undecidability proof is
built on
a category (type) error: it assumes a program and its own representation >>> (as a finite string) are interchangeable. This assumption fails under
simulating deciders, revealing a type distinction through behavioral
divergence. As such, all deciders must respect this boundary, and
diagonalization becomes ill-formed. This reframing dissolves the paradox >>> by making the Halting Problem itself an ill-posed question.
1. Operational Evidence of Type Distinction
-------------------------------------------
- When a program (e.g., `DD()`) is passed to a simulating halt decider
(`HHH`), it leads to infinite recursion.
- This behavior differs from direct execution (e.g., a crash due to a
stack overflow).
- This divergence shows that the program (as code) and its
representation
(as data) are operationally distinct.
- Therefore, treating them as the same "type" (as Turing's proof does)
leads to inconsistency.
2. Generalization to All Deciders
---------------------------------
- If simulation reveals this type mismatch, then no valid decider can
rely
on conflating program and representation.
- Diagonalization (e.g., defining D(x) = if H(x,x) then loop else halt)
necessarily crosses the type boundary.
- The contradiction in the Halting Problem arises from this type error,
not from inherent undecidability.
- Hence, the Halting Problem is ill-defined for self-referential input.
3. Comparisons to Other Formal Systems
--------------------------------------
- In type-theoretic systems (like Coq or Agda), such self-reference is
disallowed:
- Programs must be well-typed.
- Self-referential constructs like `H(x, x)` are unrepresentable if
they
would lead to paradox.
- In category theory, morphisms must respect domain/codomain boundaries: >>> - Reflexive constructions require stratification to avoid logical
inconsistency.
4. Conclusion
-------------
- The Halting Problem depends on self-reference and diagonalization.
- If these constructs are blocked due to type/category errors, the proof >>> breaks down.
- Thus, the Halting Problem isn’t undecidable—it’s malformed when it >>> crosses type boundaries.
- This is not a refutation of Turing, but a reformulation of the problem >>> under more disciplined typing rules.
This model mirrors how Russell’s Paradox was avoided in modern logic:
not
by solving the contradiction, but by redefining the terms that made the
contradiction possible.
The halting problem has very simple types: the input is two strings
and the output is a bit. The same input can be given to a UTM, so
the input type of the halting problem is the input type of a UTM.
There is no divergence of behaviour: a UTM has only one behaviour for
each input and no other UTM needs be considered.
That ignores a key fact
_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]
One or more instructions of the above function
are correctly emulated by different instances of
pure x86 emulators at machine address 000015d2.
None of these correctly emulated DDD instances halts.
It is stupidly incorrect to simply assume that the
pathological relationship between HHH and DDD does
not change the behavior of DDD when it is proven
that is does change the behavior.
HHH1(DDD) has no pathological relationship thus HHH1
never emulates itself emulating DDD.
HHH(DDD) has a pathological relationship thus HHH
emulates itself emulating DDD.
It is pretty stupid to think that above two
behaviors are identical.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 01:08:13 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,057 |
| Messages: | 6,416,577 |