experchange This is how I solved the Halting Problem

 peteolcott (06-03-19, 06:19 AM)

(1) I deduce a decision tree of very broad categories of possible solutions to analytical problems.

(2) I eliminate whole categories as either infeasible or sub-optimal.

(3) I divide the remaining category into its next increment of specificity
goto (2).
 André G. Isaak (06-03-19, 06:57 AM)
On 2019-06-02 10:19 p.m., peteolcott wrote:
>
> (1) I deduce a decision tree of very broad categories of possible
> solutions to analytical problems.
> (2) I eliminate whole categories as either infeasible or sub-optimal.
> (3) I divide the remaining category into its next increment of specificity
>     goto (2).

IOW, You haven't solved the halting problem. The halting problem asks
whether any arbitrary computer program is guaranteed to halt.

It doesn't care whether the program in question is "optimal", nor
whether it is designed to solve some particular "analytical" problem.

André
 peteolcott (06-03-19, 05:28 PM)
On 6/2/2019 11:57 PM, André G. Isaak wrote:
> On 2019-06-02 10:19 p.m., peteolcott wrote:
> IOW, You haven't solved the halting problem. The halting problem asks whether any arbitrary computer program is guaranteed to halt.
> It doesn't care whether the program in question is "optimal", nor whether it is designed to solve some particular "analytical" problem.
> André

The primary issue with solving these problems is paring away the purely extraneous details.
 André G. Isaak (06-03-19, 06:20 PM)
On 2019-06-03 9:28 a.m., peteolcott wrote:
> On 6/2/2019 11:57 PM, André G. Isaak wrote:
> The primary issue with solving these problems is paring away the purely
> extraneous details.

So why don't you demonstrate how your actual method works. Show how your
method determines whether the following function halts:

void DoIHalt {

unsigned long x = 14;

while (x != 982353739) {

x = x * 144;
x += 17;
x = x/57;

};

return;

};

André
 peteolcott (06-03-19, 06:39 PM)
On 6/3/2019 11:20 AM, André G. Isaak wrote:
[..]
>   return;
> };
> André

All of the specifications of the halting problem besides the Peter Linz one are pretty crappy.

Linz boils it down to its barest essence eliminating all of the extraneous details
while retaining all of the relevant details.

The encoded H only decides halting for exactly one encoded H^.
To the best of my current knowledge the same method used in
my example can be extended to decide halting for every TM.

> void DoIHalt {
> int x = 1;
> while (x < 10)
> x++;
> };

The current H cannot decide if the above halts.
It can decide if exactly one element of the set of all
Peter Linz H^ input pairs does halt, thus showing exactly
how the halting problem would be solved.
 André G. Isaak (06-03-19, 07:39 PM)
On 2019-06-03 10:39 a.m., peteolcott wrote:
> On 6/3/2019 11:20 AM, André G. Isaak wrote:
> All of the specifications of the halting problem besides the Peter Linz
> one are pretty crappy.
>
> Linz boils it down to its barest essence eliminating all of the
> extraneous details
> while retaining all of the relevant details.
> The encoded H only decides halting for exactly one encoded H^.

Then you haven't solved the halting problem. The halting problem should
be able to answer the question 'does this program halt' for *any*
arbitrary program.

> To the best of my current knowledge the same method used in
> my example can be extended to decide halting for every TM.
> The current H cannot decide if the above halts.

Is there some reason why you felt to change the program I gave to
something where it is trivially obvious that it halts?

André
 Andy Walker (06-03-19, 08:10 PM)
On 03/06/2019 18:39, André G. Isaak wrote:
> Then you haven't solved the halting problem. The halting problem
> should be able to answer the question 'does this program halt' for
> *any* arbitrary program.

PO has never managed to understand that the HP is not concerned
with any *particular* instance, but is to write *one* program [or TM]
that solves *all* instances. I suspect he would say "that's screwy!".
He claims that "the same method" works more generally; but that's not,
in itself, interesting.
 Ben Bacarisse (06-03-19, 10:41 PM)
Andy Walker <anw> writes:

> On 03/06/2019 18:39, André G. Isaak wrote:
> PO has never managed to understand that the HP is not concerned
> with any *particular* instance, but is to write *one* program [or TM]
> that solves *all* instances. I suspect he would say "that's screwy!".
> He claims that "the same method" works more generally; but that's not,
> in itself, interesting.

Ack. But let's not forget the specific new claim that was made last
year. He claimed to have a TM, P, that correctly decides the halting of
the single computation <[P^], [P^]>. (Here, <x, y> denotes the encoding
a pair of strings, and [M] denotes the encoding of M.) P can do
anything it likes with any other input.

The point is that P^ is derived from P in a manner that makes it
logically impossible for P to give the right answer. PO claims to have
had an example so such an impossible TM "fully encoded" since December
13th.

He has posted many excuses for not posting it. He won't even post the
number of states it has (because he wants to keep open the possibility
of changing his mind I imagine). I have no expectation of ever seeing
what he thinks he has, but he'll keep boasting about it.
 Ben Bacarisse (06-06-19, 02:44 PM)
peteolcott <Here@Home> writes:
<cut>

> The encoded H only decides halting for exactly one encoded H^.

You said H correctly decides halting for the specific input <[H^],
[H^]>. Missing out "correctly", adding "exactly one" and not giving the
actual computation, all make it look like you are backing out of your
claim.

You don't have, and have never had, the H you claimed to have all those
weeks ago. You won't post it, so no one can tell you where you've gone
wrong, but M^ is derived from M in a way that makes it logically
impossible for M to correctly decide <[M^], [M^]>. You might as well be
claiming to have found a number greater than all the numbers greater
than it. But, of course, you won't post this number until you've
finished some random C++ program that no one wants to see!

> To the best of my current knowledge the same method used in
> my example can be extended to decide halting for every TM.

The best of your current knowledge is seriously lacking, and you are
deliberately not posting the TM you so you can enjoy boasting about
having it rather than extending your current knowledge by finding out
what you've done wrong. Mind you, I suspect you don't even have a TM
"fully encoded" (as you claimed to have had for nearly six months)
because you won't even post the number of states it has. You've not
been able to come up with an excuse for not posting even that tiny
detail. I think we all know why.

> It can decide if exactly one element of the set of all
> Peter Linz H^ input pairs does halt, thus showing exactly
> how the halting problem would be solved.

That is not what you claimed before, and is so trivially possible that no
one would remark about it. I don't think you are really changing your
claim, I just think you are no better at writing English than you are at
writing mathematics, so it just seems that you are saying something
else.
 peteolcott (06-06-19, 05:19 PM)
On 6/6/2019 7:44 AM, Ben Bacarisse wrote:
[..]
> claiming to have found a number greater than all the numbers greater
> than it. But, of course, you won't post this number until you've
> finished some random C++ program that no one wants to see!

I am going to get back working on this today. I had to be the lawyer

>> To the best of my current knowledge the same method used in
>> my example can be extended to decide halting for every TM.

> The best of your current knowledge is seriously lacking, and you are
> deliberately not posting the TM you so you can enjoy boasting about
> having it rather than extending your current knowledge by finding out
> what you've done wrong.

Unless you would bet your eternal soul on that Your certainty is
less than complete.

> Mind you, I suspect you don't even have a TM
> "fully encoded" (as you claimed to have had for nearly six months)
> because you won't even post the number of states it has. You've not
> been able to come up with an excuse for not posting even that tiny
> detail. I think we all know why.
> That is not what you claimed before, and is so trivially possible that no
> one would remark about it. I don't think you are really changing your
> claim, I just think you are no better at writing English than you are at
> writing mathematics, so it just seems that you are saying something
> else.

My communication ability is pretty bad. It took me three years
to find the words to succinctly show why Tarski's proof failed
to prove his point. Tarski decided that there can be no consistent
formalized truth predicate entirely on the basis of his lack of
success of proving that a lie is true.

Tarski could not prove that a lie is true (Duh !)

It would // Tarski page 248
then be possible to reconstruct the antinomy of the liar in the
metalanguage, by forming in the language itself a sentence x
such that the sentence of the metalanguage which is correlated
with x asserts that x is not a true sentence.

the sentence x which is // Tarski page 276
undecidable in the original theory becomes a decidable sentence
in the enriched theory.

Tarski could not prove that a lie is true in his original theory.
"This sentence is not true" is not true
 Ben Bacarisse (06-07-19, 01:52 AM)
peteolcott <Here@Home> writes:

> On 6/6/2019 7:44 AM, Ben Bacarisse wrote:
> I am going to get back working on this today. I had to be the lawyer

Post the TM. Stop making excuses.

> Unless you would bet your eternal soul on that Your certainty is
> less than complete.

Post the TM. Stop making excuses.

> My communication ability is pretty bad.

I agree. Post the TM. A TM speaks for itself.

> It took me three years
> to find the words to succinctly show why Tarski's ...

Post the TM. Stop trying to distract attention from the fact that
you won't.
 peteolcott (06-07-19, 02:07 AM)
On 6/6/2019 6:52 PM, Ben Bacarisse wrote:
> peteolcott <Here@Home> writes:
> Post the TM. Stop making excuses.
> Post the TM. Stop making excuses.
> I agree. Post the TM. A TM speaks for itself.
> Post the TM. Stop trying to distract attention from the fact that
> you won't.

It is certainly not going to be reviewed here first. Even if it
was utterly infallible in every way there is only one person here
that would not disparage it anyway, and I am only 50% sure they
they would not disparage it.
 peteolcott (06-07-19, 05:22 AM)
On 6/6/2019 10:01 PM, Ben Bacarisse wrote:
> Fred <Fred> writes:
> <cut>
> For the record, he claimed to have his impossible TM (not a universal
> halting decider, but an impossible TM none the less) "fully encoded" on
> 13th Dec 2018.

You conflated two different things that I said.
 peteolcott (06-07-19, 05:33 AM)
On 6/6/2019 10:07 PM, Ben Bacarisse wrote:
> peteolcott <Here@Home> writes:
>> I have one H that decides halting for exactly one (H^, H^) input pair.

> You should say "I have a TM H that correctly decides halting for (H^,
> H^)". Your phrasing raises doubts that you are still talking about the
> impossible TM you had "fully encoded" six months ago.

I completed the algorithm design December 13th 2018 at the Westroad's
mall Gold and Diamond booth with my Friend Akmal. I completed this work
on the the glass case at the South East end of the booth at about 6:40 PM.

My precious little dog Bella died that same night.

I completed fully encoding TM H and TM H^ sometime prior to
February 25, 2019, that is the file date of my most recent
work on this project.
 Ben Bacarisse (06-09-19, 01:48 AM)
peteolcott <Here@Home> writes:

> On 6/6/2019 10:07 PM, Ben Bacarisse wrote:
> I completed the algorithm design December 13th 2018 ... at about 6:40
> PM.

Ah, so you lied (or at least dissembled) on Jan 7th[1] when you replied
to my question:

|| Are you now admitting you don't even have the TM you've claimed
|| to have for weeks and weeks? That would be a shocking deception, but
|| sadly, not one that would surprise me.

with

| I have had it since December 13 at 6:00 PM.

Note: "TM", not "algorithm".

> I completed fully encoding TM H and TM H^ sometime prior to
> February 25, 2019, that is the file date of my most recent
> work on this project.