- Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) - 9 Updates
- Refraining from embracing - 2 Updates
- Mapping "C" to a Turing equivalent abstract model of computation - 2 Updates
- cannot find C++ regex tester - 2 Updates
- Hex ASCII to raw binary on Unix-like - 1 Update
| olcott <NoOne@NoWhere.com>: Sep 05 12:40AM -0500 On 9/4/2020 11:50 PM, André G. Isaak wrote: > purely hypothetical TM which is claimed to decide halting for every > possible input but whose workings are not described. > André Linz provides a very simple state machine definition of H. It has one start state (q0) and two final states ((qy)) and ((qn)) having a wildcard state transitions in-between. The H_Hat variation merely prepends a well defined state (copy input) and appends a pair of infinite loop states. The key unspecified aspect of these machines is the transition from (q0) to (qy) or (qn). Everything else is totally specified. These wildcard state transitions essentially allow any computation that gets the right answer. This all boils down to anything that I specify that gets the right answer in-between (q0) and (qy) or (qn) counts as valid. http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Sep 05 02:16PM -0500 On 9/5/2020 1:33 PM, André G. Isaak wrote: >> until you get it. > Nothing in your definition mentions anything about "instances". I'm > asking you to explain what you mean by "at least one instance". It is analogous to usage in OOP between a class and an instance of a class. Linz H (q0)---->(HDC)---->((qy)) or ((qn)) based on some halting deciding code in (HDC). Linz Ĥ (q0)---->(qx)---->(HDX)---->(qy)---->(infinite_loop) or ((qn)) based on same halting deciding code in (HDC). As long as the halt deciding code in HDC is the same in H and H_Hat and shows that its decision is correct then the Linz proof has been refuted. I don't have to show that H can correctly decide halting for every possible encoding of the halting code. I only have to show that it is not the H / H_hat template that prevents a correct halting decision. When I do this then every conventional self-referential halting problem counter-example will have been refuted along with the only basis of all of these proofs. http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf Linz, Peter 1990. An Introduction to Formal Languages and Automata. Lexington/Toronto: D. C. Heath and Company. -- Copyright 2020 Pete Olcott |
| Richard Damon <Richard@Damon-Family.org>: Sep 05 04:19PM -0400 On 9/5/20 3:16 PM, olcott wrote: > As long as the halt deciding code in HDC is the same in H and H_Hat and > shows that its decision is correct then the Linz proof has been refuted. And how do you show the answer is correct when it is always wrong by definition? If the HDC determines that H_Hat WILL halt, then H_Hat, by its definition needs to infinitely loop, so the determination that it will halt is incorrect. If the HDC determines that H_Hat will not halt, then H_Hat, by its definition needs to halt, then the determination that it will not halt is incorrect. If the HDC does not determine what will happen, it violates its requirement as a HDC, and is thus incorrect. |
| olcott <NoOne@NoWhere.com>: Sep 05 03:31PM -0500 On 9/5/2020 3:19 PM, Richard Damon wrote: >> shows that its decision is correct then the Linz proof has been refuted. > And how do you show the answer is correct when it is always wrong by > definition? When we actually see H correctly deciding an instance of H_Hat we find that prior understanding of the Halting Problem as impossible by definition is an incorrect understanding. > is incorrect. > If the HDC does not determine what will happen, it violates its > requirement as a HDC, and is thus incorrect. There is a loophole. -- Copyright 2020 Pete Olcott |
| Richard Damon <Richard@Damon-Family.org>: Sep 05 05:19PM -0400 On 9/5/20 4:31 PM, olcott wrote: > When we actually see H correctly deciding an instance of H_Hat we find > that prior understanding of the Halting Problem as impossible by > definition is an incorrect understanding. So what does your machine do???? I suspect, fail to meet the requirements. >> If the HDC does not determine what will happen, it violates its >> requirement as a HDC, and is thus incorrect. > There is a loophole. Only by redefining that you are solving a different problem using (I suppose) some other fundamental axioms of logic. I hope that you have fully examined your new axioms that you are working on. If you REALLY have a loophole in the proof, because the proof is so simple, the loophole should have a fairly simple description. A wildly complicated counter is certainly going to be like the proofs of 1 == 2 that rely on hiding a division by 0 in them. My guess is you have missed some characteristic of true Turing Machines (which can't physically exist as they have potentially infinite memory). It is well known that the Halting problem CAN be solved for a memory limited Turing Machine, even by another memory limited (but much bigger memory) Turing Machine. My first guess is either you have that sort of flaw, or you are failing to provide the answer in true Finite time. |
| "André G. Isaak" <agisaak@gm.invalid>: Sep 05 03:28PM -0600 On 2020-09-05 13:16, olcott wrote: >> asking you to explain what you mean by "at least one instance". > It is analogous to usage in OOP between a class > and an instance of a class. I don't see the analogy. Nor do I see how it relates to your definition of Turing equivalent computation. > Linz Ĥ > (q0)---->(qx)---->(HDX)---->(qy)---->(infinite_loop) or ((qn)) > based on same halting deciding code in (HDC). What are qx and HDX? André -- To email remove 'invalid' & replace 'gm' with well known Google mail service. |
| "André G. Isaak" <agisaak@gm.invalid>: Sep 05 03:29PM -0600 On 2020-09-05 14:31, olcott wrote: >> If the HDC does not determine what will happen, it violates its >> requirement as a HDC, and is thus incorrect. > There is a loophole. And what is this loophole? André -- To email remove 'invalid' & replace 'gm' with well known Google mail service. |
| "André G. Isaak" <agisaak@gm.invalid>: Sep 05 03:52PM -0600 On 2020-09-05 14:31, olcott wrote: > When we actually see H correctly deciding an instance of H_Hat we find > that prior understanding of the Halting Problem as impossible by > definition is an incorrect understanding. Since you claim to have have had your solution "fully encoded" at one time, then you should be able to answer the following very simple question: When given your <Ĥ, Ĥ> as input, does your program claim that this halts or that it doesn't halt. No need to provide any details of how it arrives at the answer -- you can continue to keep that secret -- I just want to know what answer it actually gives. André -- To email remove 'invalid' & replace 'gm' with well known Google mail service. |
| Mike Terry <news.dead.person.stones@darjeeling.plus.com>: Sep 05 11:01PM +0100 On 05/09/2020 22:19, Richard Damon wrote: > memory) Turing Machine. > My first guess is either you have that sort of flaw, or you are failing > to provide the answer in true Finite time. My guess would be that he's not properly understood the relation between H (the decider) and H_Hat (the test case). Either his H_Hat will be wildly off in relationship to H, or the correspondence will be broken in some more subtle (but not that subtle!) way. E.g. he could "cheat" through H being passed some kind of hidden input other than its legitimate input (H^Hat, H_Hat), enabling it to behave differently when it's invoked internally within H_Hat. (Input from global variables? Something in his emulator implementation? ...) But he's not going to give any details, so we'll just have to wait and see... Mike. |
| Brian Wood <woodbrian77@gmail.com>: Sep 05 10:27AM -0700 On Thursday, March 26, 2020 at 2:33:17 AM UTC-5, Ian Collins wrote: > > Are people rethinking on-line code generation now > > that the cat is out of the bag with the Wuhan virus? > It's Covid-19 and no. Twat. It looks like the mob is going after this comp sci professor now: https://www.foxnews.com/us/ucla-students-replace-computer-science-chair They stab it with their steely knives, but they just can't kill the truth. I'd be happy to work with that prof. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Sep 05 09:34PM +0100 On 05/09/2020 18:27, Brian Wood wrote: > They stab it with their steely knives, but they just > can't kill the truth. I'd be happy to work with that > prof. That is because you are a bigot like him. Fuck off twat. /Flibble -- "Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| olcott <NoOne@NoWhere.com>: Sep 05 11:38AM -0500 There is no possible way for any concrete implementation of "C" to be made equivalent to a Turing machine. If we used every atom in the whole universe to each store a single binary digit we would still be woefully short of unlimited memory. We can override and supersede the standard "C" and map its syntax and semantics to an abstract model of computation that is Turing equivalent. The RASP model of computation is a model that "C" can be mapped to. https://en.wikipedia.org/wiki/Random-access_stored-program_machine A variation of the RASP model is shown below that the x86/x64 language maps to. Since it is already known that "C" maps to the x86/x64 concrete models of computation we know that "C" maps to the following abstract model: Instruction : INTEGER ":" OPCODE // Address:Opcode | INTEGER ":" OPCODE INTEGER // Address:Opcode Operand | INTEGER ":" OPCODE INTEGER "," INTEGER // Address:Opcode Operand, Operand HEXDIGIT [a-fA-F0-9] INTEGER {HEXDIGIT}+ OPCODE HEXDIGIT{4} The above abstract machine maps the x86 language to machines with a fixed pointer size of the largest unlimited integer address that is actually needed by the computation. This provides the basis for recognizing the set of Turing equivalent x86/x64/C computations. Turing equivalent computations derive equivalent output or fail to halt on equivalent input between the concrete machine and its Turing machine equivalent. Some machines that (for example) count to infinity and store the counter at each increment do not map to any finite computation. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Sep 05 11:41AM -0500 There is no possible way for any concrete implementation of "C" to be made equivalent to a Turing machine. If we used every atom in the whole universe to each store a single binary digit we would still be woefully short of unlimited memory. We can override and supersede the standard "C" and map its syntax and semantics to an abstract model of computation that is Turing equivalent. The RASP model of computation is a model that "C" can be mapped to. https://en.wikipedia.org/wiki/Random-access_stored-program_machine A variation of the RASP model is shown below that the x86/x64 language maps to. Since it is already known that "C" maps to the x86/x64 concrete models of computation we know that "C" maps to the following abstract model: Instruction : INTEGER ":" OPCODE // Address:Opcode | INTEGER ":" OPCODE INTEGER // Address:Opcode Operand | INTEGER ":" OPCODE INTEGER "," INTEGER // Address:Opcode Operand, Operand HEXDIGIT [a-fA-F0-9] INTEGER {HEXDIGIT}+ OPCODE HEXDIGIT{4} The above abstract machine maps the x86 language to machines with a fixed pointer size of the largest unlimited integer address that is actually needed by the computation. This provides the basis for recognizing the set of Turing equivalent x86/x64/C computations. Turing equivalent computations derive equivalent output or fail to halt on equivalent input between the concrete machine and its Turing machine equivalent. Some machines that (for example) count to infinity and store the counter at each increment do not map to any finite computation. -- Copyright 2020 Pete Olcott |
| RM <robert_magdziarz@wp.pl>: Sep 05 10:28AM +0200 I tried to write my own C++ regex tester, but it doesn't work for multiline input, I don't know why. /* Simple regex tester Gets regex, reads text from standard input, writes matches to standard output */ #include <iostream> #include <string> #include <regex> using namespace std; int main(int argc, char *argv[]) { if (argc != 2) { cerr << "Usage: " << argv[0] << " regular_expression <input_file" << endl; return EXIT_FAILURE; } regex re(argv[1], std::regex_constants::multiline); stringstream buffer; buffer << cin.rdbuf(); string text = buffer.str(); cmatch cm; regex_match(text.c_str(), cm, re); for (unsigned int i = 0; i < cm.size(); ++i) { cout << cm.str(i) << endl; } return EXIT_SUCCESS; } |
| RM <robert_magdziarz@wp.pl>: Sep 05 12:58PM +0200 W dniu 05.09.2020 o 10:28, RM pisze: > } > return EXIT_SUCCESS; > } I also tried (std::regex_constants::match_not_bol | std::regex_constants::match_not_eol), without success. match_not_bol Not Beginning-Of-Line The first character is not considered a beginning of line ("^" does not match). match_not_eol Not End-Of-Line The last character is not considered an end of line ("$" does not match). |
| Sam <sam@email-scan.com>: Sep 04 09:00PM -0400 Frederick Gotham writes: > most basic way of achieving my objective -- that will work on pretty much > every Unix-like system. > Lots of embedded Linux systems don't have hexdump, xxd, od, bc. od and hexdump are the most basic way to accomplish it. Trying to roll your own only ends up reinventing the same wheels. They are tiny. $ size /usr/bin/hexdump text data bss dec hex filename 46758 2432 240 49430 c116 /usr/bin/hexdump Your "hello world" will not be far off the mark from this one. So, if you need to convert something with the smallest possible footprint, you already have it: hexdump. The most you can gain from writing your own code is saving yourself writing the code in hexdump that produces the handful of other formats, other than hex. |
| 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