- Onwards and upwards - 5 Updates
- More explanation of my poem of Love - 2 Updates
- A non-halting decider is defined - 2 Updates
- It is known that a correct halt decider must return false (in this case)[V3] - 2 Updates
| Brian Wood <woodbrian77@gmail.com>: Nov 22 11:19AM -0800 On Saturday, October 17, 2020 at 7:23:06 PM UTC-5, Brian Wood wrote: > https://duckduckgo.com/?q=cppcon+2020&t=h_&iar=videos&iax=videos&ia=videos&iai=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3De8SyxB3_mnw > Performance Matters by Emery Berger > https://duckduckgo.com/?q=cppcon++2020+videos&iax=videos&ia=videos&iai=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DkoTf7u0v41o The C++ Middleware Writer is similar to Reese's candy: bringing together services and code generation in a single cookie. G-d willing, and with your ideas on how to improve it, it will continue to improve. Tia Brian Ebenezer Enterprises https://github.com/Ebenezer-group/onwards |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Nov 22 08:49PM On 22/11/2020 19:19, Brian Wood wrote: > bringing together services and code generation in a > single cookie. G-d willing, and with your ideas on how > to improve it, it will continue to improve. Tia Your fucking god doesn't fucking exist. Yes, I will fucking swear here. #atheism /Flibble -- ¬ |
| Brian Wood <woodbrian77@gmail.com>: Nov 22 01:36PM -0800 On Sunday, November 22, 2020 at 2:50:04 PM UTC-6, Mr Flibble wrote: With "leaders" like the Clintons, W. Bush, Obamas, Trump, Biden and Harris, services are the way things have to be now. "For the scientist who has lived by his faith in the power of reason, the story ends like a bad dream. He has scaled the mountains of ignorance, he is about to conquer the highest peak; as he pulls himself over the final rock, he is greeted by a band of theologians who have been sitting there for centuries." ― Robert Jastrow, G-d and the Astronomers "We few, few happy few..." http://www.poetryatlas.com/poetry/poem/4722/we-few%2C-we-happy-few....html Brian Ebenezer Enterprises https://webEbenezer.net |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Nov 22 09:46PM On 22/11/2020 21:36, Brian Wood wrote: > as he pulls himself over the final rock, he is greeted by a band > of theologians who have been sitting there for centuries." > ― Robert Jastrow, G-d and the Astronomers Robert Jastrow was a fucking idiot climate change denier. Now fuck off with your off-topic religious spam, spammer. #atheism /Flibble -- ¬ |
| Brian Wood <woodbrian77@gmail.com>: Nov 22 02:18PM -0800 On Sunday, November 22, 2020 at 3:46:28 PM UTC-6, Mr Flibble wrote: Either try to be helpful or go back to your threads. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 22 06:09PM +0100 Don't you think you earn 5 billion dollars with this poem by selling it to 100 million people ? Am 22.11.2020 um 16:18 schrieb Amine Moulay Ramdane: |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Nov 22 05:31PM On 22/11/2020 17:09, Bonita Montero wrote: > Don't you think you earn 5 billion dollars with > this poem by selling it to 100 million people ? No. Take your meds please. /Flibble -- ¬ |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Nov 22 03:26AM -0800 >> true then there is no counterexample to be found, and the TM will >> run forever. > To me, the surprising thing is the size. [...] I didn't think about that at all. I don't have any sense for either how big the question (about ZFC) is, or what Turing Machines with a given number of states might be able to do. Since I don't have any kind of framework in which to evaluate it, I really didn't even notice the number. > Maybe the issue is what you mean by "[it] is always possible to answer > the question". Finite sets are decidable, but I would not have phrased > it as you did (assuming that is all you meant). I was trying to make a different point, about the nature of Turing Machines, and which appears to be in need of further explanation. |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Nov 22 04:54AM -0800 > particular. I'm contending that not only do such TM machines exist, but > that they're relatively small and some (whose halting status is > undecidable) are already known. I think you're confusing being decidable and being provable. If we are concerned with only a single input TM (call it Z), then there is a TM (call it D) that tells us whether Z halts or not. Because Z is fixed, either it halts or it doesn't. Hence D can be one of two simple TMs: one that outputs "yes" and halts, or one that outputs "no" and halts. We may not know which one is right, but certainly one of those two answers the question (and answers it correctly). > that this (fairly small) TM doesn't halt on a ZFC inconsistency will > require a proof from outside the relm of computing if such a proof can > exist at all. A TM that tells us whether the machine Z halts isn't obliged to supply a proof that its answer is correct, only to produce the right answer. If we want to prove that a particular proposed machine does indeed produce the right answer then proving that is up to us. But there isn't any doubt that a TM that does give the correct answer actually exists, even if we don't know which one it is. > Even some relatively simple things - e.g. counting up to the value of > BB(8000) - must be impossible because we know that any <8k state TM > must halt in less than BB(8000) steps or run forever. You mean it's impossible for a machine with only 8000 states, right? Since BB(8000) is a fixed and finite number, certainly there is a TM (with more than 8000 states) that can count up to BB(8000). More generally, for any finite number N, there is a TM H(N) that can tell us whether a TM that has N (or fewer) states will halt. The machine H(N) works by simulating its input for BB(N) steps. If the simulated machine hasn't halted by that time then it never will. Even though we don't know what the value of BB(N) actually is, there isn't any question that H(N) exists for every finite N. Does that all make sense? > on its input tape writes N-1, N-2, N-3 ... 1 after it (each number > separated by a blank) and then terminates. > Therefore BB(8000) must be "unknowable" The number BB(8000) is so unimaginably large that I doubt we will ever know much about it. However, isn't it the case that the number BB(8000) can be produced by a TM with only 8001 states? It's been a while since I've looked at this stuff but I'm pretty sure that's right, at least above some moderately small size. By the way, if your comments about BB(8000) are based on some sort of connection to the logic of ZFC then I am missing that, since I don't have much background in what ZFC implies. But I think my comments above about TMs are correct and are not affected by matters dependent on ZFC consistency. |
| olcott <NoOne@NoWhere.com>: Nov 21 06:02PM -0600 (1) It is known that the UTM simulation of a machine's Turing machine description is equivalent to directly executing it. 01 void H_Hat(u32 P) 02 { 03 if (Halts(P, P)) 04 HERE: goto HERE; 05 else 06 HALT 07 } 08 bool Halts(u32 P, u32 I) 09 { 10 bool Halted = false; 11 bool Aborted = false; 12 while (!Halted && !Aborted) 13 { 14 Halted = DebugStep(P, I); 15 Aborted = Needs_To_Be_Aborted(); 16 } 17 return !Aborted; 18 } 19 int main() 20 { 21 u32 P = (u32)H_Hat; 22 Halts(P, P); 23 HALT; 24 } (2) It is known that the above code is infinitely recursive if Halts() acts like a UTM (by having its line 15 disabled) and simulates its input returning true if and only if its input halts. (3) On the basis of (1) and (2) It is known that a correct halt decider for H_Hat (without line 15 disabled) must return false. -- Copyright 2020 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Nov 22 12:48AM On 22/11/2020 00:02, olcott wrote: > 24 } > (2) It is known that the above code is infinitely recursive if Halts() acts like a UTM (by having its line 15 disabled) and simulates its input returning true if and only if its input halts. > (3) On the basis of (1) and (2) It is known that a correct halt decider for H_Hat (without line 15 disabled) must return false. Take your meds. /Flibble -- ¬ |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment