- OT: Help to disprove this theory - 5 Updates
- Detecting infinite recursion - 11 Updates
- Detecting infinite recursion (V2) - 9 Updates
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Mar 04 11:42AM -0500 Do you know of anyone who can disprove this theory either scientifically or Biblically? https://www.youtube.com/watch?v=oGdVtSh4wRs It's a theory that states our solar system was created by God in the beginning to manufacture subsequent Earths. Each Earth exists for a "season" which is the 7,000 Biblical cycle of in-service duty. This is followed by reclamation and recycling as the next planet steps up to serve the role of the next Earth, as the current Earth goes into recycling. The theory follows from the natural lines we see on the NOAA and GEBCO maps indicating the Earth used to be smaller (trace the lines backward and they all fit together on a smaller Earth). The size of the smaller Earth and the current Earth's size indicated hints at the planets in line being part of a solar system assembly line of sorts. The rest of the manufacturing process also naturally followed from that realization. You can see THE EARTH SEA FLOOR MAPS on the links at http://www.3alive.org. There's source code for the simulation at that link also if interested. I'd really like it if someone could disprove this theory. It's been a burden for me to bear since 2009. I'd like some hard fact that could say it absolutely could not be like this. -- Rick C. Hodgin |
| Lew Pitcher <lew.pitcher@digitalfreehold.ca>: Mar 04 06:43PM On Thu, 04 Mar 2021 11:42:59 -0500, Rick C. Hodgin wrote: > Do you know of anyone who can disprove this theory either scientifically > or Biblically? [snip] It is not ours to disprove; it is yours to prove 1) "onus probandi", which is the obligation on a party in a dispute to provide sufficient warrant for their position. 2) Hitchens's razor: What can be asserted without evidence can also be dismissed without evidence. 3) The "Sagan standard": extraordinary claims require extraordinary evidence -- Lew Pitcher "In Skills, We Trust" |
| Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk>: Mar 04 06:55PM On 04/03/2021 18:43, Lew Pitcher wrote: > evidence. > 3) The "Sagan standard": > extraordinary claims require extraordinary evidence Well put but it will fall of deaf ears I'm afraid as the spamming trolling idiot relies on faith and the irrational rather than science, logic and the rational. /Flibble -- π |
| Lew Pitcher <lew.pitcher@digitalfreehold.ca>: Mar 04 06:57PM On Thu, 04 Mar 2021 18:43:21 +0000, Lew Pitcher wrote: > evidence. > 3) The "Sagan standard": > extraordinary claims require extraordinary evidence See, also, "Russell's teapot", in that the philosophic burden of proof lies upon a person making unfalsifiable claims, rather than shifting the burden of disproof to others. -- Lew Pitcher "In Skills, We Trust" |
| Bonita Montero <Bonita.Montero@gmail.com>: Mar 04 08:21PM +0100 Can you please post your thoughts where they are appropriate ? |
| mickspud@potatofield.co.uk: Mar 04 09:23AM On Wed, 3 Mar 2021 21:00:41 +0000 (UTC) >>>to be a definable number? >> It has a quantifiable value. >What does that even mean? It means it has a value that can be written down using actual numbers. >I think you are making stuff up as you go. As I've said before, English is not your first language so I won't blame you for not following everything. |
| mickspud@potatofield.co.uk: Mar 04 09:23AM On Wed, 03 Mar 2021 14:18:44 -0800 >> I think you are making stuff up as you go. >I think he's making stuff up that has even less to do with C++ than the >original topic of this thread. I suggest not replying. You do realise this is usenet? Topics drift. |
| David Brown <david.brown@hesbynett.no>: Mar 04 11:42AM +0100 >>> It has a quantifiable value. >> What does that even mean? > It means it has a value that can be written down using actual numbers. That is not what it would mean to a mathematician. It's good enough, perhaps, for a lot school maths. At a higher level, the term "number" can be dependent on the context. /You/ probably just mean "decimal digit", judging by your comment here. But to anyone interested in mathematics beyond school level, "number" will usually mean "real number" unless context dictates something else (integer, complex number, transfinite number, length of a line, etc.). You can't have a sensible conversation about mathematics (or indeed any topic) if you insist on using your own limited definitions that are different from other people's. You just make yourself look silly, arguing about "defined values" when all you are trying to say is basic facts about rational numbers that are well known to everyone else in the thread. Here's a clue for you - when everyone else in the discussion agrees with each other, and disagrees with you, then either you have got your terms wrong, or you are out of your depth. Many of us are happy to give you pointers on what you are getting wrong here, but you have to cooperate and understand that you /are/ wrong, rather than responding with insults and totally misplaced patronisation. >> I think you are making stuff up as you go. > As I've said before, English is not your first language so I won't blame you > for not following everything. Juha's written English is more accurate than yours. I believe I could point out a dozen (minor) errors in the spelling and grammar of your posts in this thread - I'm not sure I could find any in Juha's posts. It would certainly be petty of me to do so, but hopefully you can see the inappropriateness of railing on Juha's language skills. |
| mickspud@potatofield.co.uk: Mar 04 10:56AM On Thu, 4 Mar 2021 11:42:12 +0100 >mathematics beyond school level, "number" will usually mean "real >number" unless context dictates something else (integer, complex number, >transfinite number, length of a line, etc.). Oh ok, thanks for the heads up there Euclid. >> for not following everything. >Juha's written English is more accurate than yours. I believe I could >point out a dozen (minor) errors in the spelling and grammar of your No doubt you could, I don't bother to use a spell checker given its usenet. >posts in this thread - I'm not sure I could find any in Juha's posts. >It would certainly be petty of me to do so, but hopefully you can see >the inappropriateness of railing on Juha's language skills. No, not really. Spelling is irrelevant, comprehension is far more important. I can speak passable French but I write it like a Martian. Far more useful than the other way around. No kindly shove your patronising attitude up your arse and fuck off. |
| David Brown <david.brown@hesbynett.no>: Mar 04 12:21PM +0100 On 04/03/2021 11:56, mickspud@potatofield.co.uk wrote: <snip the irrelevant bits> If you value comprehension of what people write, then try re-reading the thread and comprehending what others have said. Once you have understood where you went wrong, you'll perhaps have learned something. In the meantime, perhaps we could get back to C++. |
| Bonita Montero <Bonita.Montero@gmail.com>: Mar 04 01:09PM +0100 Can you pleas stop posting things not related to C/C++-language issues to comp.lang.c++/c ? |
| Juha Nieminen <nospam@thanks.invalid>: Mar 04 01:56PM >>> It has a quantifiable value. >>What does that even mean? > It means it has a value that can be written down using actual numbers. You can't write the entire decimal expansion of 1/3. Consider *why* you think that you can, and then consider how is that different from, for example, sqrt(2) or pi. (Hint: What you can do is give a description, a definition, an algorithm to write arbitrarily many of the digits of the decimal expansion of that number. The same is true for all three examples above.) sqrt(2) and pi are not any less "well-defined" as 1/3 is. The exact algorithm to print out arbitrarily many digits of their decimal expansion may be a bit more complicated, but that means nothing in this context. >>I think you are making stuff up as you go. > As I've said before, English is not your first language so I won't blame you > for not following everything. One has to wonder why you feel the need to be so arrogant and condescending. Ironically, I think I know English better than you. At least I know what a "definable number" is. |
| MrMeep@edgeoftheuniverse.com: Mar 04 03:34PM On Thu, 4 Mar 2021 13:56:37 +0000 (UTC) >>>What does that even mean? >> It means it has a value that can be written down using actual numbers. >You can't write the entire decimal expansion of 1/3. At the risk of getting drawn into this - the expansion of 1/3 can easily be written in a number of bases since its rational number. An irrational number cannot be written down in ANY real base. |
| olcott <NoOne@NoWhere.com>: Mar 04 09:46AM -0600 > At the risk of getting drawn into this - the expansion of 1/3 can easily be > written in a number of bases since its rational number. An irrational number > cannot be written down in ANY real base. Thus algorithmic compression seems apt. -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| David Brown <david.brown@hesbynett.no>: Mar 04 05:19PM +0100 > At the risk of getting drawn into this - the expansion of 1/3 can easily be > written in a number of bases since its rational number. An irrational number > cannot be written down in ANY real base. You can write any number x as 10 in base x. That applies to any /real/ number - there is nothing (except perhaps a concern for your own sanity) stopping you using base Ο positional number systems. (Indeed, you don't have to restrict yourself to real numbers.) Representations are all just invented for convenience - you can invent any new own you like in order to write down what you want. Simple integer base positional numeral systems are merely the ones with which we are most familiar. <https://en.wikipedia.org/wiki/Non-integer_base_of_numeration#Base_%CF%80> You could define an "irrational number" as being a real number which cannot be written using a finite sequence of digits in any integer base representation. That would be a perfectly good definition - equivalent to more common definitions. But it bears no relationship to whether a number is "defined" or has a "value". Mick's argument that Ο does not have a "defined value" because you can't write it in a finite decimal expansion bears no more validity than saying "a tenth" does not have a "defined value" because you can't write it in Roman numerals. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Mar 04 10:00AM -0800 On 3/4/2021 5:56 AM, Juha Nieminen wrote: >>> What does that even mean? >> It means it has a value that can be written down using actual numbers. > You can't write the entire decimal expansion of 1/3. 0.333... ;^) |
| olcott <NoOne@NoWhere.com>: Mar 04 08:51AM -0600 If a software function: (1) Simulates the execution of the machine language of another function. (2) Maintains an execution trace list of each machine state change occurring as a result of the simulation of each machine instruction. (3) Examines this list after the execution of each machine instruction for the purpose of detecting whether or not the Simulate() function is being called in infinite recursion. (4) Stops simulating the program under test as soon as it detects that Simulate is being called in infinite recursion. void H_Hat(u32 P) { Simulate(P, P); } int main() { Simulate((u32)H_Hat, (u32)H_Hat); } Can this Simulate() function correctly decide not halting on its input on the basis that it did correctly detect that it was being called in infinite recursion? -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| Bonita Montero <Bonita.Montero@gmail.com>: Mar 04 04:19PM +0100 Can you pleas stop posting things not related to C/C++-language issues to comp.lang.c++/c ? |
| olcott <NoOne@NoWhere.com>: Mar 04 09:26AM -0600 On 3/4/2021 9:19 AM, Bonita Montero wrote: > Can you pleas stop posting things not related to C/C++-language > issues to comp.lang.c++/c ? I meant to put a followup-To comp.theory on the, sorry. -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| Richard Damon <Richard@Damon-Family.org>: Mar 04 10:55AM -0500 On 3/4/21 9:51 AM, olcott wrote: > Can this Simulate() function correctly decide not halting on its input > on the basis that it did correctly detect that it was being called in > infinite recursion? A SIMULATOR, which never stops until the program it is running stops, can detect infinte execution this way. Once you hit step 4, and the simulator changes its computation based on this behavior, then the simulator need to understand the behivor when it is invoked recursively and handles it. That is the crux of the flaw in your system. Step for introduces a conditional into the loop that is capable of breaking the otherwise infinite recursion, and once that conditional become part of the computation it is analyzing, it needs to take that conditional into account which breaks most of the rules that you can use to detect the infinite execution. |
| David Brown <david.brown@hesbynett.no>: Mar 04 04:59PM +0100 On 04/03/2021 15:51, olcott wrote: > being called in infinite recursion. > (4) Stops simulating the program under test as soon as it detects that > Simulate is being called in infinite recursion. You can't detect if a program has infinite recursion or not. (I.e., you can't detect if it will halt or not - the "infinite recursion" is just a distraction, as the problem is equivalent.) In any finite number of steps, you can only be sure that the function has stopped within that number of steps, or has not yet stopped. You can't (in general) know if it will continue. I suspect that your ideas about simulation - in particular, simulating x86 assembly - have given you a warped view of the whole problem. You are restricting everything to a limited finite size. Ultimately this gives you a limit that does not exist in general. If you are dealing only with programs written in x86 machine code that fit within 2 ^ 32 bytes of combined program and data space (as indicated by your "u32" type), then there will be a limit to the number of cycles that a program can run if it is ever going to halt (for a given input). And the potential range of inputs is known and finite (since the machine is limited) - so you can just take the maximum over all possible programs and all possible inputs. Call that number N. Run your simulator for at most N steps. If the simulated program has stopped, you know it halts. If it has not, you know it can never halt. (The size of N here is absurdly huge, of course.) But the "halting problem" is about general programs - not a limited subset of programs. There are no limits to the sizes involved. The proof that you can't solve the halting problem is really quite simple. Suppose you have made a function (or program - the terms are equivalent) "halts" that returns "true" if a program halts, and "false" if it does not. Then you can write the function: function bad() : if halts(bad) then loop forever() If "bad" halts, then "halts(bad)" is true and "bad" loops forever - so "bad" does not halt. If "bad" does not halt, then "halts(bad)" returns false and bad() finishes - it does not halt. It is /that/ simple. You can put more effort into it to formalise a proof - or just look up a proof on the net. But that's a rough sketch, and is enough to show you that the halting problem is not computable. |
| olcott <NoOne@NoWhere.com>: Mar 04 10:04AM -0600 On 3/4/2021 9:55 AM, Richard Damon wrote: >> infinite recursion? > A SIMULATOR, which never stops until the program it is running stops, > can detect infinte execution this way. No it cannot because it never makes any decision in all of eternity. > computation it is analyzing, it needs to take that conditional into > account which breaks most of the rules that you can use to detect the > infinite execution. If the halt decider is answering the question: Does the input program halt? Then "no" is the wrong answer. If the halt decider is answering the question: Does the simulation of the input program have to be terminated to prevent its otherwise infinite execution? Then "yes" is the correct answer. -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| olcott <NoOne@NoWhere.com>: Mar 04 10:08AM -0600 On 3/4/2021 9:59 AM, David Brown wrote: > You can't detect if a program has infinite recursion or not. (I.e., you > can't detect if it will halt or not - the "infinite recursion" is just a > distraction, as the problem is equivalent.) Sure you can here is a concrete example: #include <stdint.h> #define u32 uint32_t int Simulate(u32 P, u32 I) { ((void(*)(u32))P)(I); } void H_Hat(u32 P) { Simulate(P, P); } int main() { Simulate((u32)H_Hat, (u32)H_Hat); } _Simulate() [00000478](01) 55 push ebp [00000479](02) 8bec mov ebp,esp [0000047b](03) 8b450c mov eax,[ebp+0c] [0000047e](01) 50 push eax [0000047f](03) ff5508 call dword [ebp+08] [00000482](03) 83c404 add esp,+04 [00000485](01) 5d pop ebp [00000486](01) c3 ret _H_Hat() [00000868](01) 55 push ebp [00000869](02) 8bec mov ebp,esp [0000086b](03) 8b4508 mov eax,[ebp+08] [0000086e](01) 50 push eax [0000086f](03) 8b4d08 mov ecx,[ebp+08] [00000872](01) 51 push ecx [00000873](05) e800fcffff call 00000478 [00000878](03) 83c408 add esp,+08 [0000087b](01) 5d pop ebp [0000087c](01) c3 ret _main() [00000888](01) 55 push ebp [00000889](02) 8bec mov ebp,esp [0000088b](05) 6868080000 push 00000868 [00000890](05) 6868080000 push 00000868 [00000895](05) e8defbffff call 00000478 [0000089a](03) 83c408 add esp,+08 [0000089d](02) 33c0 xor eax,eax [0000089f](01) 5d pop ebp [000008a0](01) c3 ret Columns (1) Sequence number (2) Machine address of instruction (3) Machine address of top of stack (4) Value of top of stack after instruction executed (5) Number of bytes of machine code (6) Machine language bytes (7) Assembly language text (01)[00000888][00011194][00000000](01) 55 push ebp (02)[00000889][00011194][00000000](02) 8bec mov ebp,esp (03)[0000088b][00011190][00000868](05) 6868080000 push 00000868 (04)[00000890][0001118c][00000868](05) 6868080000 push 00000868 (05)[00000895][00011188][0000089a](05) e8defbffff call 00000478 Line (03) pushes second parameter to Simulate() machine address 0x868 Line (04) pushes first parameter to Simulate() machine address 0x868 Line (05) Calls Simulate(0x868, 0x868); (06)[00000868][00011178][00011184](01) 55 push ebp (07)[00000869][00011178][00011184](02) 8bec mov ebp,esp (08)[0000086b][00011178][00011184](03) 8b4508 mov eax,[ebp+08] (09)[0000086e][00011174][00000868](01) 50 push eax (10)[0000086f][00011174][00000868](03) 8b4d08 mov ecx,[ebp+08] (11)[00000872][00011170][00000868](01) 51 push ecx (12)[00000873][0001116c][00000878](05) e800fcffff call 00000478 Line (09) pushes second parameter to Simulate() machine address 0x868 Line (11) pushes first parameter to Simulate() machine address 0x868 Line (12) Calls Simulate(0x868, 0x868); (13)[00000868][0001115c][00011168](01) 55 push ebp (14)[00000869][0001115c][00011168](02) 8bec mov ebp,esp (15)[0000086b][0001115c][00011168](03) 8b4508 mov eax,[ebp+08] (16)[0000086e][00011158][00000868](01) 50 push eax (17)[0000086f][00011158][00000868](03) 8b4d08 mov ecx,[ebp+08] (18)[00000872][00011154][00000868](01) 51 push ecx (19)[00000873][00011150][00000878](05) e800fcffff call 00000478 Line (16) pushes second parameter to Simulate() machine address 0x868 Line (18) pushes first parameter to Simulate() machine address 0x868 Line (19) Calls Simulate(0x868, 0x868); Now we have seen that Simulate() is invoked two times from the same machine address of H_Hat() with the same data. We also know that Simulate() either executes or emulates the machine language of its input and nothing more. This seems to provide a sufficient basis for deciding that H_Hat() is infinitely recursive, thus non-halting. -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| olcott <NoOne@NoWhere.com>: Mar 04 10:29AM -0600 On 3/4/2021 10:17 AM, Richard Damon wrote: > your claims. > But, since you seem to keep making the claims that they do, we will keep > pointing out that you are wrong. I have reframed the halting problem** such that a universal halt decider can no longer be shown to be impossible. **Removing its pathological self-reference(Olcott 2004) By doing this the conventional halting problem proof counter-examples become halting decidable. void H_Hat(u32 P) { u32 Input_Halts = Halts(P, P); if (Input_Halts) HERE: goto HERE; return; } int main() { u32 Input_Would_Halt = Halts((u32)H_Hat, (u32)H_Hat); Output("Input_Would_Halt = ", Input_Would_Halt); } -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| olcott <NoOne@NoWhere.com>: Mar 04 11:12AM -0600 On 3/4/2021 10:44 AM, Richard Damon wrote: > Yes, maybe you can say that with your new Olcott Infinite Recursion > problem, the proofs like Linz do not apply. That doesn't say you have > come up with a counter in the domain of the Conventional Halting Problem. The reason that I can do this is that my revision to the halting problem criteria provides the means for a universal halt decider to exist. The only reason that the original halting problem is undecidable is because it was asking an incorrect question. sci.lang Jan 31, 2015, 7:58:34 PM Is the concept of [incorrect question] new? https://groups.google.com/g/sci.lang/c/lSdYexJ0ozo/m/aDN9-TYLHwIJ Feb 20, 2015, 11:38:48 AM The logical law of polar questions https://groups.google.com/g/sci.lang/c/AO5Vlupeelo/m/nxJy7N2vULwJ The revised question: Does the simulation of the input program have to be stopped to prevent its infinite execution? Eliminates the pathological self-reference(Olcott 2004) error of the halting problem question. -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| 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