Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable

Liste des GroupesRevenir à theory 
Sujet : Re: Formal systems that cannot possibly be incomplete except for unknowns and unknowable
De : polcott333 (at) *nospam* gmail.com (olcott)
Groupes : comp.theory
Date : 07. May 2025, 21:58:33
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vvghhp$1867c$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
User-Agent : Mozilla Thunderbird
On 5/7/2025 3:53 PM, dbush wrote:
On 5/7/2025 4:39 PM, olcott wrote:
On 5/7/2025 3:07 PM, dbush wrote:
On 5/7/2025 4:03 PM, olcott wrote:
On 5/7/2025 1:38 PM, dbush wrote:
On 5/7/2025 2:35 PM, olcott wrote:
On 5/7/2025 1:18 PM, dbush wrote:
On 5/7/2025 1:55 PM, olcott wrote:
On 5/6/2025 11:16 AM, Richard Heathfield wrote:
On 06/05/2025 16:38, Alan Mackenzie wrote:
These aren't particularly difficult things to comprehend.  As I keep
saying, you ought to show a lot more respect for people who are
mathematically educated.
>
I concur.
>
As someone who is not particularly mathematically educated (I have an A- level in the subject, but that's all), I tend to steer well clear of mathematical debates, although I have occasionally dipped a toe.
>
I have *enormous* respect for those who know their tensors from their manifolds and their conjectures from their eigenvalues, even though it's all Greek to me.
>
But to understand the Turing proof requires little if any mathematical knowledge. It requires only the capacity for clear thinking.
>
Having been on the receiving end of lengthy Usenet diatribes by cranks in my own field, I don't hold out much hope for our current culprits developing either the capacity for clear thought or any measure of respect for expertise any time soon.
>
Nor do I believe they are capable of understanding proof by contradiction, which is just about the easiest kind of proof there is. In fact, the most surprising aspect of this whole affair is that
>
>
(according to Mike) Mr Olcott seems to have (correctly) spotted a minor flaw in the proof published by Dr Linz. How can he get that and not get contradiction? Proof by contradiction is / much/ easier.
>
>
When THERE IS NO CONTRADICTION then proof by contradiction fails.
>
False.  The contradiction is that HHH is found to not map the below function after it is assumed that the below function is computable and that HHH computes it:
>
>
Given any algorithm (i.e. a fixed immutable sequence of instructions) X described as <X> with input Y:
>
A solution to the halting problem is an algorithm H that computes the following mapping:
>
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly
>
>
>
In other words you absolutely refuse to begin
to understand to notion of computing the mapping
from an input.
>
>
>
I'll let you respond to yourself:
>
On 10/12/2024 8:35 PM, olcott wrote:
 > That your rebuttals are pure bluster utterly bereft of any
 > supporting reasoning is clear to all having sufficient
 > technical understanding.
>
>
In other words you absolutely refuse to understand
that functions computed by models of computation
are only allowed to derive outputs by applying
the steps of an algorithm to their actual inputs.
>
>
No, it is you that doesn't understand that there is no requirement that any mapping has an algorithm that can compute it.
>
I know that.
 Then you know that when we assume the contrary for the halting function, we get a contradiction.
 
What you do not seem to know
is that an incoherent requirement does not
place any limit on computation.
 There is nothing incoherent about the halting function:
  Given any algorithm (i.e. a fixed immutable sequence of instructions) X described as <X> with input Y:
 A solution to the halting problem is an algorithm H that computes the following mapping:
 (<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly
 
>
That calculating the radius of a square circle
cannot be computed places no actual limit on computation.
>
The int sum(int x, int y) { return x + y; }
>
Requiring HHH to report on behavior that is different
that the behavior that its actual input actually specifies
 False, as "DD" is a representation of the algorithm DD which halts when executed directly.  This is proven by UTM(DD) halting.
 
is exactly the same as requiring sum(3,2) to report on
the sum of 5 + 7.
>
The halting mapping is one such mapping, as Linz and others have proved and as you have *explicitly* agreed is correct.
>
I said they were correct ONLY ON THE BASIS OF A THE FALSE
ASSUMPTION that an input can actually do the opposite
of whatever value that its termination analyzer reports.
 That is not an assumption.  That is proven through a series of truth preserving operations.  This gives us a contradiction, proving the assumption that the halting function is computable is false, as Linz and others have proved and as you have *explicitly* agreed is correct.
 
There never has been any contradiction when we compute
the mapping from the finite string input to the behavior
that this input actually specifies.
The contradiction only comes when we "compute" the
mapping on the basis of a quote from a text book.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

Date Sujet#  Auteur
5 Jan 26 o 

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal