Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.software-eng > #3809
| From | olcott <polcott333@gmail.com> |
|---|---|
| Newsgroups | comp.theory, sci.logic, sci.math, comp.lang.prolog, comp.software-eng |
| Subject | Re: The Halting Problem asks for too much |
| Date | 2026-01-12 08:43 -0600 |
| Organization | A noiseless patient Spider |
| Message-ID | <10k31b1$2dfd4$1@dont-email.me> (permalink) |
| References | (7 earlier) <10jt29l$313jd$1@dont-email.me> <10jtsaa$38qmt$1@dont-email.me> <10jvtkc$3qq6h$1@dont-email.me> <10k0bo6$3uvrl$1@dont-email.me> <10k2jod$29c3h$1@dont-email.me> |
Cross-posted to 5 groups.
On 1/12/2026 4:51 AM, Mikko wrote:
> On 11/01/2026 16:23, olcott wrote:
>> On 1/11/2026 4:22 AM, Mikko wrote:
>>> On 10/01/2026 17:47, olcott wrote:
>>>> On 1/10/2026 2:23 AM, Mikko wrote:
>>>>> On 09/01/2026 17:52, olcott wrote:
>>>>>> On 1/9/2026 3:59 AM, Mikko wrote:
>>>>>>> On 08/01/2026 16:22, olcott wrote:
>>>>>>>> On 1/8/2026 4:22 AM, Mikko wrote:
>>>>>>>>> On 07/01/2026 13:54, olcott wrote:
>>>>>>>>>> On 1/7/2026 5:49 AM, Mikko wrote:
>>>>>>>>>>> On 07/01/2026 06:44, olcott wrote:
>>>>>>>>>>>> All deciders essentially: Transform finite string
>>>>>>>>>>>> inputs by finite string transformation rules into
>>>>>>>>>>>> {Accept, Reject} values.
>>>>>>>>>>>>
>>>>>>>>>>>> The counter-example input to requires more than
>>>>>>>>>>>> can be derived from finite string transformation
>>>>>>>>>>>> rules applied to this specific input thus the
>>>>>>>>>>>> Halting Problem requires too much.
>>>>>>>>>>
>>>>>>>>>>> In a sense the halting problem asks too much: the problem is
>>>>>>>>>>> proven to
>>>>>>>>>>> be unsolvable. In another sense it asks too little: usually
>>>>>>>>>>> we want to
>>>>>>>>>>> know whether a method halts on every input, not just one.
>>>>>>>>>>>
>>>>>>>>>>> Although the halting problem is unsolvable, there are partial
>>>>>>>>>>> solutions
>>>>>>>>>>> to the halting problem. In particular, every counter-example
>>>>>>>>>>> to the
>>>>>>>>>>> full solution is correctly solved by some partial deciders.
>>>>>>>>>>
>>>>>>>>>> *if undecidability is correct then truth itself is broken*
>>>>>>>>>
>>>>>>>>> Depends on whether the word "truth" is interpeted in the standard
>>>>>>>>> sense or in Olcott's sense.
>>>>>>>>
>>>>>>>> Undecidability is misconception. Self-contradictory
>>>>>>>> expressions are correctly rejected as semantically
>>>>>>>> incoherent thus form no undecidability or incompleteness.
>>>>>>>
>>>>>>> The misconception is yours. No expression in the language of the
>>>>>>> first
>>>>>>> order group theory is self-contradictory. But the first order goupr
>>>>>>> theory is incomplete: it is impossible to prove that AB = BA is true
>>>>>>> for every A and every B but it is also impossible to prove that
>>>>>>> AB = BA
>>>>>>> is false for some A and some B.
>>>>>>>
>>>>>>
>>>>>> All deciders essentially: Transform finite string
>>>>>> inputs by finite string transformation rules into
>>>>>> {Accept, Reject} values.
>>>>>>
>>>>>> When a required result cannot be derived by applying
>>>>>> finite string transformation rules to actual finite
>>>>>> string inputs, then the required result exceeds the
>>>>>> scope of computation and must be rejected as an
>>>>>> incorrect requirement.
>>>>>
>>>>> No, that does not follow. If a required result cannot be derived by
>>>>> appying a finite string transformation then the it it is uncomputable.
>>>>
>>>> Right. Outside the scope of computation. Requiring anything
>>>> outside the scope of computation is an incorrect requirement.
>>>>
>>>>> Of course, it one can prove that the required result is not computable
>>>>> then that helps to avoid wasting effort to try the impossible. The
>>>>> situation is worse if it is not known that the required result is not
>>>>> computable.
>>>>>
>>>>> That something is not computable does not mean that there is anyting
>>>>> "incorrect" in the requirement.
>>>>
>>>> Yes it certainly does. Requiring the impossible is always an error.
>>>
>>> It is a perfectly valid question to ask whther a particular reuqirement
>>> is satisfiable.
>>
>> Any yes/no question lacking a correct yes/no answer
>> is an incorrect question that must be rejected on
>> that basis.
>
> Irrelevant. The question whether a particular requirement is satisfiable
> does have an answer that is either "yes" or "no". In some ases it is
> not known whether it is "yes" or "no" and there may be no known way to
> find out be even then either "yes" or "no" is the correct answer.
>
Now that I finally have the standard terminology:
Proof-theoretic semantics has always been the correct
formal system to handle decision problems.
When it is asked a yes/no question lacking a correct
yes/no answer it correctly determines non-well-founded.
I have been correct all along and merely lacked the
standard terminology.
--
Copyright 2026 Olcott<br><br>
My 28 year goal has been to make <br>
"true on the basis of meaning expressed in language"<br>
reliably computable.<br><br>
This required establishing a new foundation<br>
Back to comp.software-eng | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
The Halting Problem asks for too much olcott <polcott333@gmail.com> - 2026-01-06 22:44 -0600
Re: The Halting Problem asks for too much Mikko <mikko.levanto@iki.fi> - 2026-01-07 13:49 +0200
Re: The Halting Problem asks for too much olcott <polcott333@gmail.com> - 2026-01-07 05:54 -0600
Re: The Halting Problem asks for too much Mikko <mikko.levanto@iki.fi> - 2026-01-08 12:22 +0200
Re: The Halting Problem asks for too much olcott <polcott333@gmail.com> - 2026-01-08 08:22 -0600
Re: The Halting Problem asks for too much Mikko <mikko.levanto@iki.fi> - 2026-01-09 11:59 +0200
Re: The Halting Problem asks for too much olcott <polcott333@gmail.com> - 2026-01-09 09:52 -0600
Re: The Halting Problem asks for too much Mikko <mikko.levanto@iki.fi> - 2026-01-10 10:23 +0200
Re: The Halting Problem asks for too much olcott <polcott333@gmail.com> - 2026-01-10 09:47 -0600
Re: The Halting Problem asks for too much Richard Damon <news.x.richarddamon@xoxy.net> - 2026-01-10 18:19 -0500
Re: The Halting Problem asks for too much olcott <polcott333@gmail.com> - 2026-01-10 18:13 -0600
Re: The Halting Problem asks for too much Richard Damon <news.x.richarddamon@xoxy.net> - 2026-01-10 19:35 -0500
Re: The Halting Problem asks for too much olcott <polcott333@gmail.com> - 2026-01-10 18:52 -0600
Re: The Halting Problem asks for too much Richard Damon <news.x.richarddamon@xoxy.net> - 2026-01-10 21:03 -0500
Re: The Halting Problem asks for too much olcott <polcott333@gmail.com> - 2026-01-10 20:22 -0600
Re: The Halting Problem asks for too much Richard Damon <news.x.richarddamon@xoxy.net> - 2026-01-10 21:34 -0500
Computation and Undecidability olcott <polcott333@gmail.com> - 2026-01-10 21:24 -0600
Re: Computation and Undecidability Richard Damon <news.x.richarddamon@xoxy.net> - 2026-01-10 22:32 -0500
Re: The Halting Problem asks for too much Mikko <mikko.levanto@iki.fi> - 2026-01-11 12:13 +0200
Re: The Halting Problem asks for too much olcott <polcott333@gmail.com> - 2026-01-11 08:18 -0600
Re: The Halting Problem asks for too much Mikko <mikko.levanto@iki.fi> - 2026-01-12 12:44 +0200
Re: The Halting Problem asks for too much Mikko <mikko.levanto@iki.fi> - 2026-01-11 12:22 +0200
Re: The Halting Problem asks for too much olcott <polcott333@gmail.com> - 2026-01-11 08:23 -0600
Re: The Halting Problem asks for too much Mikko <mikko.levanto@iki.fi> - 2026-01-12 12:51 +0200
Re: The Halting Problem asks for too much olcott <polcott333@gmail.com> - 2026-01-12 08:43 -0600
Re: The Halting Problem asks for too much Richard Damon <Richard@Damon-Family.org> - 2026-01-12 22:22 -0500
Re: The Halting Problem asks for too much Mikko <mikko.levanto@iki.fi> - 2026-01-13 10:46 +0200
Re: The Halting Problem asks for too much olcott <polcott333@gmail.com> - 2026-01-13 08:17 -0600
Re: The Halting Problem asks for too much Mikko <mikko.levanto@iki.fi> - 2026-01-14 09:58 +0200
Re: The Halting Problem asks for too much Mikko <mikko.levanto@iki.fi> - 2026-01-14 11:04 +0200
Re: The Halting Problem asks for too much olcott <polcott333@gmail.com> - 2026-01-14 13:35 -0600
Re: The Halting Problem asks for too much Mikko <mikko.levanto@iki.fi> - 2026-01-15 11:21 +0200
Computation and Undecidability olcott <polcott333@gmail.com> - 2026-01-10 17:19 -0600
Re: Computation and Undecidability Richard Damon <news.x.richarddamon@xoxy.net> - 2026-01-10 19:35 -0500
Re: Computation and Undecidability olcott <polcott333@gmail.com> - 2026-01-10 19:03 -0600
Re: Computation and Undecidability Richard Damon <news.x.richarddamon@xoxy.net> - 2026-01-10 21:03 -0500
Re: Computation and Undecidability olcott <polcott333@gmail.com> - 2026-01-10 20:20 -0600
Re: Computation and Undecidability Richard Damon <news.x.richarddamon@xoxy.net> - 2026-01-10 21:33 -0500
Re: Computation and Undecidability olcott <polcott333@gmail.com> - 2026-01-10 21:18 -0600
Re: Computation and Undecidability Richard Damon <news.x.richarddamon@xoxy.net> - 2026-01-10 22:30 -0500
Re: Computation and Undecidability olcott <polcott333@gmail.com> - 2026-01-10 19:05 -0600
Re: Computation and Undecidability Richard Damon <news.x.richarddamon@xoxy.net> - 2026-01-10 21:03 -0500
Re: Computation and Undecidability olcott <polcott333@gmail.com> - 2026-01-10 20:09 -0600
Re: Computation and Undecidability Richard Damon <news.x.richarddamon@xoxy.net> - 2026-01-10 21:33 -0500
Re: Computation and Undecidability olcott <polcott333@gmail.com> - 2026-01-10 21:16 -0600
Re: Computation and Undecidability Richard Damon <news.x.richarddamon@xoxy.net> - 2026-01-10 22:28 -0500
Re: Computation and Undecidability olcott <polcott333@gmail.com> - 2026-01-10 21:34 -0600
Re: Computation and Undecidability Richard Damon <news.x.richarddamon@xoxy.net> - 2026-01-11 06:31 -0500
Re: Computation and Undecidability olcott <polcott333@gmail.com> - 2026-01-11 08:03 -0600
Haskell Curry Foundations of Mathematical Logic sense of true in the system olcott <polcott333@gmail.com> - 2026-01-09 09:47 -0600
csiph-web