Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Why halt deciders can't be "interesting" programs. (HP refutation)
11 views
Skip to first unread message
olcott
Sep 12, 2020, 3:47:25 PM9/12/20
to
On 9/12/2020 2:01 PM, Malcolm McLean wrote:
> On Saturday, 12 September 2020 at 18:46:39 UTC+1, olcott wrote:
>>
>> The worst sin of humanity (having the most grievous consequences) is
>> equating unbelievable with false and believable with true.
>>
>> -I will soon have a partial halt decider sufficiently equivalent
>> -to the Linz H correctly deciding halting on the Linz Ĥ proving
>> -that Ĥ on input Ĥ is halting decidable.
>> -
> You want your results to be published. What you don't seem to understand,
> and to be fair what other people in this discussion maybe also don't
> understand, is that if you submit to a journal, they won't be interested
> in your C code. They'll ask for the proof that Linz was wrong. Which could
> consist of a description of the principle on which your code works. But no
> -one referee is going to inspect anything other than the simplest snippet of C
> for errors. Referees simply don't have time.
>
When-so-ever I submit anything less than 100% perfectly complete total
proof (such as H actually deciding halting on H_Hat) in this forum
everyone is so certain that I must be incorrect that they never bother
to see that I am correct.
> Now I don't believe that such a proof is possible. However I am still asking
> for it because, as I have explained, it might be worth something to you if it
> is sufficiently succinct and it looks superficially plausible.
>
There is nothing more certain that a program sufficiently equivalent to
H can decide halting on a program sufficiently equivalent to H_Hat than
the actual program actually doing this.
H returns a Boolean result and every step of the derivation of this
Boolean result is provided. An execution trace is more reliable than a
formal proof because proofs can have mistakes whereas actually executing
code actually executes as it actually executes.
> However if I can't spot an error in it, and no-one else here can point out an
> error, then who are we to say that it is a fallacious proof? But we'll come
> to that when we come to it.
>
Yes my current goal is to have 100% complete results published
(at least here) on the two year anniversary of my discovery:
December 13, 2018 @ 7:00 PM. My plan for achieving this is to have
everything totally complete 30 days from now, thus providing a two
months safety margin to meet my anniversary date.
The x86 based UTM equivalent seems totally complete except for this:
Virtual Machine Instruction (operating system function call)
// The master machine executes the slave machine
void DebugStep(u32* master_state, u32* slave_state);
All of the infrastructure for this including the every-single-detail
design is in place, complete and passed testing.
There was a bug with the COFF object file patch relocation code now
fixed, and generalized to work with Microsoft assembly language and "C"
generated COFF files. The code runs correctly on Microsoft and Linux.
--
Copyright 2020 Pete Olcott
> On Saturday, 12 September 2020 at 18:46:39 UTC+1, olcott wrote:
>>
>> The worst sin of humanity (having the most grievous consequences) is
>> equating unbelievable with false and believable with true.
>>
>> -I will soon have a partial halt decider sufficiently equivalent
>> -to the Linz H correctly deciding halting on the Linz Ĥ proving
>> -that Ĥ on input Ĥ is halting decidable.
>> -
> You want your results to be published. What you don't seem to understand,
> and to be fair what other people in this discussion maybe also don't
> understand, is that if you submit to a journal, they won't be interested
> in your C code. They'll ask for the proof that Linz was wrong. Which could
> consist of a description of the principle on which your code works. But no
> -one referee is going to inspect anything other than the simplest snippet of C
> for errors. Referees simply don't have time.
>
When-so-ever I submit anything less than 100% perfectly complete total
proof (such as H actually deciding halting on H_Hat) in this forum
everyone is so certain that I must be incorrect that they never bother
to see that I am correct.
> Now I don't believe that such a proof is possible. However I am still asking
> for it because, as I have explained, it might be worth something to you if it
> is sufficiently succinct and it looks superficially plausible.
>
There is nothing more certain that a program sufficiently equivalent to
H can decide halting on a program sufficiently equivalent to H_Hat than
the actual program actually doing this.
H returns a Boolean result and every step of the derivation of this
Boolean result is provided. An execution trace is more reliable than a
formal proof because proofs can have mistakes whereas actually executing
code actually executes as it actually executes.
> However if I can't spot an error in it, and no-one else here can point out an
> error, then who are we to say that it is a fallacious proof? But we'll come
> to that when we come to it.
>
Yes my current goal is to have 100% complete results published
(at least here) on the two year anniversary of my discovery:
December 13, 2018 @ 7:00 PM. My plan for achieving this is to have
everything totally complete 30 days from now, thus providing a two
months safety margin to meet my anniversary date.
The x86 based UTM equivalent seems totally complete except for this:
Virtual Machine Instruction (operating system function call)
// The master machine executes the slave machine
void DebugStep(u32* master_state, u32* slave_state);
All of the infrastructure for this including the every-single-detail
design is in place, complete and passed testing.
There was a bug with the COFF object file patch relocation code now
fixed, and generalized to work with Microsoft assembly language and "C"
generated COFF files. The code runs correctly on Microsoft and Linux.
--
Copyright 2020 Pete Olcott
Richard Damon
Sep 12, 2020, 6:57:44 PM9/12/20
to
Runs H(H^,H^) and returns a result.
Runs H^(H^) which will run H(H^,H^) which will return the same result
Then H^ either loops if H returned Halted, or Halts if H returned Loops
And the result of H says H^(H^) halted if it does halt and loops if it
does loop.
Since if H say Halts, then H^ will loop, or if it says Loop it will
Halt, it seems impossible to make H predict correctly if H^ works as
required.
SO there are basically 3 binary facts that are interesting, H(H^,H^)
result, What H^(H^) did, and perhaps we will want what the copy of H
inside H^ returned,
olcott
Sep 12, 2020, 7:31:08 PM9/12/20
to
the halting problem proofs are anchored in a fundamental misconception.
Richard Damon
Sep 12, 2020, 8:48:58 PM9/12/20
to
On 9/12/20 7:30 PM, olcott wrote:
> That is a great analysis, yet possibly incorrect if the whole idea of
> the halting problem proofs are anchored in a fundamental misconception.
>
And I don't understand what a working simulation of a Turing Machine
> That is a great analysis, yet possibly incorrect if the whole idea of
> the halting problem proofs are anchored in a fundamental misconception.
>
will help if you intend to invalidate the basic rules of logic used to
describe them.
olcott
Sep 12, 2020, 9:01:06 PM9/12/20
to
to refute the halting problem proofs.
I did point out that the mathematical definition of incompleteness
applied to formal systems does decide that a formal system is incomplete
on the basis that it cannot prove a self-contradictory statement.
A theory T is incomplete if and only if there is some sentence φ such
that (T ⊬ φ) and (T ⊬ ¬φ).
0 new messages