

(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 suboptimal. (3) I divide the remaining category into its next increment of specificity goto (2). 


On 20190602 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 suboptimal. > (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é 


On 6/2/2019 11:57 PM, André G. Isaak wrote:
> On 20190602 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. 


On 20190603 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é 


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. 


On 20190603 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é 


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. 


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. 


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. 


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 of two court cases that had strict deadlines. >> 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 


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 > of two court cases that had strict deadlines. 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. 


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. 


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. Your old memory is fading... You conflated two different things that I said. 


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. 


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. Let me help you with your failing memory. Two days later on Dec 15th[2] you said "I now have a fully encoded pair of Turing Machines H / Ä¤ proving them wrong". The twoday difference struck me as odd since it's not clear how you "have a TM" without it being encoded in some way. But it seems you misapoke. You had the TM on 15th, not the 13th. Anyway, six months ago (depending on how you count your months), and you still can't post the numbers of states it has. And you proably won't ever post a TM. You don't have it, do you? [1] MessageID: <3sudnZEDA9sk7K7BnZ2dnUU7fnNnZ2d> [2] MessageID: <JbydneYGrrpProjBnZ2dnUU7X3NnZ2d> 

Similar Threads  