- Hex ASCII to raw binary on Unix-like - 1 Update
- Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation Sufficiency Specs) - 11 Updates
- Clarification of PO's UTM architecture and his H and H_Hat - 2 Updates
- Crackpots (was Re: Transforming "C" into a Turing equivalent ...) - 1 Update
- cannot find C++ regex tester - 2 Updates
- Refraining from embracing - 1 Update
Vir Campestris <vir.campestris@invalid.invalid>: Sep 06 09:55PM +0100 On 04/09/2020 18:38, Frederick Gotham wrote: > Like this: > some_other_program | sed 's/../\\x&/g' | xargs echo -e > Can anyone think of an even more simple way? You have sed (109000 bytes on my system) but not xxd (18552 bytes)? You picked the wrong tools. Andy |
Jeff Barnett <jbb@notatt.com>: Sep 05 05:52PM -0600 On 9/5/2020 4:01 PM, Mike Terry wrote: > 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? ...) Experience has shown he's not intelligent enough to make those kind of mistakes unless utterly by accident. Also there is a lot of troll in him and the only detectable trait is that he wants people to respond to his inanities. Just remember that he claimed to have all of this ready to go, i.e. coded, around two years ago - lies of course - and this is all a rearguard action to cover his ego. In other, words don't expect to ever see a TM or equivalent encoding for H. -- Jeff Barnett |
Richard Damon <Richard@Damon-Family.org>: Sep 05 09:12PM -0400 On 9/5/20 7:52 PM, Jeff Barnett wrote: > ever see a TM or equivalent encoding for H. >> But he's not going to give any details, so we'll just have to wait and >> see... My first guess, is that he somehow thinks that if H doesn't say Halted, that is good enough to be considered as the 'Not Halting' answer, when of course it isn't. That or some other 'small' change to the ground rules, that would actually allow H to be something trivial or uninteresting, so proving that this modified H can exist actully means nothing. |
olcott <NoOne@NoWhere.com>: Sep 05 09:49PM -0500 On 9/5/2020 5:01 PM, Mike Terry wrote: > But he's not going to give any details, so we'll just have to wait and > see... > Mike. Linz H (q0)---->(HDC)---->((qy)) or ((qn)) based on some halting deciding code in (HDC). Linz Ĥ (q0)---->(qx)---->(HDC)---->(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. The halting code is the only unspecified detail of H or Ĥ. I make sure that the halting code is the same in H and Ĥ by having them both call the same function. 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. http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf -- Copyright 2020 Pete Olcott |
Mike Terry <news.dead.person.stones@darjeeling.plus.com>: Sep 06 04:35AM +0100 On 06/09/2020 03:49, olcott wrote: > The halting code is the only unspecified detail of H or Ĥ. > I make sure that the halting code is the same in H and Ĥ by having them > both call the same function. That is a sensible way to do it. Also, of course, the /input/ to H when H decides (Ĥ, Ĥ) must be the same as the input to the embedded copy of H within Ĥ when Ĥ runs with input (Ĥ). That should essentially be guaranteed by the coding of Ĥ assuming it is correctly related to H, but also the embedded H cannot receive any "hidden" input from global variables or elsewhere. (This can't happen with a TM, as input is exactly what is on the tape and nothing more, and that is precisely (Ĥ, Ĥ) [suitably encoded etc.] in both situations.) To save possible problems here, it would be clearest to simply ban global variables - they are not required, since all required input can simply be passed to routines explicitly, and banning them eliminates one possible source of objection to whatever you finally deliver. Mike. |
olcott <NoOne@NoWhere.com>: Sep 05 10:50PM -0500 On 9/5/2020 10:35 PM, Mike Terry wrote: > simply be passed to routines explicitly, and banning them eliminates one > possible source of objection to whatever you finally deliver. > Mike. Yes the only actual global variables that are needed are needed by the UTM environment itself to keep track of heap allocations of memory. Because user code can store a pointer to its heap allocated memory it needs no global data at all. I don't currently know of a way to distinguish between global data and static local data or I could simply ban access to global data by user code. It may say somewhere in the COFF file how to tell the difference. -- Copyright 2020 Pete Olcott |
olcott <NoOne@NoWhere.com>: Sep 05 10:58PM -0500 On 9/5/2020 10:35 PM, Mike Terry wrote: > global variables - they are not required, since all required input can > simply be passed to routines explicitly, and banning them eliminates one > possible source of objection to whatever you finally deliver. There an easy way to ban access to global variables by user code. That is a good idea I think I will implement it as a compile time switch. -- Copyright 2020 Pete Olcott |
Richard Damon <Richard@Damon-Family.org>: Sep 06 08:47AM -0400 On 9/5/20 10:49 PM, olcott wrote: > Linz H > (q0)---->(HDC)---->((qy)) or ((qn)) > based on some halting deciding code in (HDC). Should be Linz H(M,x) That makes the decision based on whether the machine M with input x will halt or not. > Linz Ĥ > (q0)---->(qx)---->(HDC)---->(qy)---->(infinite_loop) or ((qn)) > based on same halting deciding code in (HDC). Linz Ĥ(M, x) That makes the decision based on whether the machine M with input x will halt or not Not sure where (qx) came from, and the or is placed a bit awkward too. I might write it as: (q0)---->(HDC)---->((qn)) or (qy)---->(infinite_loop) > 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. > http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf You need to break the paradox that Linz Ĥ(Ĥ, Ĥ) doesn't have a valid answer. That would require either showing an answer it could give that meets the requirement (some sort of Non-Halting Halting??), or that somehow the construction of Ĥ some how is an impossibility even if we can make a H. I suppose the latter could be describe as it is not the H / H_Hat template that prevents a correct halting decision, but that seems to be awkward wording, and seems more like trying to open up some wiggle room for inserting a fallacious argument. |
olcott <NoOne@NoWhere.com>: Sep 06 11:42AM -0500 On 9/6/2020 7:47 AM, Richard Damon wrote: > Not sure where (qx) came from, and the or is placed a bit awkward too. I > might write it as: > (q0)---->(HDC)---->((qn)) or (qy)---->(infinite_loop) (qx) come from a correction to the Linz definition of H_hat having two start states. > / H_Hat template that prevents a correct halting decision, but that > seems to be awkward wording, and seems more like trying to open up some > wiggle room for inserting a fallacious argument. I explain it all here in terms of the Linz diagrams. http://www.liarparadox.org/Linz_Diagrams.pdf -- Copyright 2020 Pete Olcott |
"André G. Isaak" <agisaak@gm.invalid>: Sep 06 11:43AM -0600 On 2020-09-06 10:42, olcott wrote: > (qx) come from a correction to the Linz definition of H_hat having two > start states. You're going to have to clarify this. Where does Linz do this and how does your qx correct this? André -- To email remove 'invalid' & replace 'gm' with well known Google mail service. |
olcott <NoOne@NoWhere.com>: Sep 06 01:04PM -0500 On 9/6/2020 12:43 PM, André G. Isaak wrote: > You're going to have to clarify this. Where does Linz do this and how > does your qx correct this? > André Look at the Linz definition of H_Hat and notice that he has two (q0) start states one after the other. I changed the name of the second one to (qx). I also wrote this succinct summary detailing the architecture of how my x86 based UTM equivalent implements H and H_Hat. http://www.liarparadox.org/Linz_Diagrams.pdf -- Copyright 2020 Pete Olcott |
olcott <NoOne@NoWhere.com>: Sep 06 01:08PM -0500 On 9/5/2020 8:12 PM, Richard Damon wrote: > rules, that would actually allow H to be something trivial or > uninteresting, so proving that this modified H can exist actully means > nothing. I explain the architecture of my solution here: http://www.liarparadox.org/Linz_Diagrams.pdf -- Copyright 2020 Pete Olcott |
olcott <NoOne@NoWhere.com>: Sep 06 12:22PM -0500 On 9/6/2020 11:00 AM, Mike Terry wrote: >> directly execute COFF object files. > Will you be making the emulator (source code) available as part of your > delivery? Better than that, I will be making it available first. >> execute COFF object files representing x86 code. > A minor question (just curious): a COFF file can contain many function > implementations, so how would the emulator know which was the entry point? The assumption is that the COFF file is generated by a Microsoft "C" compiler, thus the entry point is always main(). >> be initialized or they don't exist at all. >> The only output is an assembly language execution trace. > OK, but how does my C code get a value into EAX? If I included a return Here are all of the details of a complete example: // "C" Source code unsigned int Test() { return 0x12345678; } int main() { Test(); __asm hlt } // Intel XED Disassembly b4: 55 push ebp b5: 8BEC mov ebp, esp b7: E803000000 call 0xbf bc: F4 hlt bd: 5D pop ebp be: C3 ret bf: 55 push ebp c0: 8BEC mov ebp, esp c2: B878563412 mov eax, 0x12345678 c7: 5D pop ebp c8: C3 ret // Debug Trace [00b4] 55 push ebp [00b5] 8bec mov ebp,esp [00b7] e803000000 call 000000bf [00bf] 55 push ebp [00c0] 8bec mov ebp,esp [00c2] b878563412 mov eax,12345678 [00c7] 5d pop ebp [00c8] c3 ret [00bc] f4 hlt The halt decider is executed this same way, returning a value to main() this same way. > question for the C coding itself (do I just code void Add (int a, int b) > {...} and assume inputs are passed as a,b), and also for the scenario > where I want to run the program in your emulator. Its just regular ordinary "C" code that generates regular ordinary COFF object files with the Microsoft "C" compiler. The only thing that makes an x86 emulator into a UTM equivalent are four operating system function calls that the master UTM equivalent provides to its user programs: // Saves the state of the current virtual-machine void SaveState(u32* s); // Loads the state of a saved virtual-machine void LoadState(u32* s); // Allocates memory from the heap u32* Allocate(u32 size); // The master machine executes the slave machine void DebugStep(u32* master_state, u32* slave_state); Each user code UTM equivalent can be the master to its own slave to an arbitrary recursion depth. > But the decider function does not return, right? it somehow executes a > HLT instruction. > Mike. unsigned int H() is invoked from main() and returns to main() where main() reaches HLT and halts. (see complete example above). -- Copyright 2020 Pete Olcott |
olcott <NoOne@NoWhere.com>: Sep 06 12:40PM -0500 On 9/6/2020 12:22 PM, olcott wrote: >>> be initialized or they don't exist at all. >>> The only output is an assembly language execution trace. >> OK, but how does my C code get a value into EAX? If I included a return Here is a slightly more complete example. // "C" source code unsigned int Test2() { return 0x12345678; } int main() { unsigned int M = Test2(); __asm hlt } // Intel XED Disassembly b4: 55 push ebp b5: 8BEC mov ebp, esp b7: 51 push ecx b8: E808000000 call 0xc5 bd: 8945FC mov dword ptr [ebp-0x4], eax c0: F4 hlt c1: 8BE5 mov esp, ebp c3: 5D pop ebp c4: C3 ret c5: 55 push ebp c6: 8BEC mov ebp, esp c8: B878563412 mov eax, 0x12345678 cd: 5D pop ebp ce: C3 ret // Execution trace [00b4] 55 push ebp [00b5] 8bec mov ebp,esp [00b7] 51 push ecx [00b8] e808000000 call 000000c5 [00c5] 55 push ebp [00c6] 8bec mov ebp,esp [00c8] b878563412 mov eax,12345678 [00cd] 5d pop ebp [00ce] c3 ret [00bd] 8945fc mov [ebp-04],eax [00c0] f4 hlt -- Copyright 2020 Pete Olcott |
Jorgen Grahn <grahn+nntp@snipabacken.se>: Sep 06 02:38PM On Mon, 2020-08-31, Keith Thompson wrote: > I encourage anyone in comp.lang.c or comp.lang.c++ who wants to > reply to these posts to take a look at comp.theory, which has been > dominated by these arguments for years. And now, six days later, the normal/crackpot ratio in both comp.lang.c and comp.lang.c++ has dropped to close to zero. (Not that it was very high to begin with, especially not in comp.lang.c.) /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
Paavo Helde <eesnimi@osa.pri.ee>: Sep 06 11:09AM +0300 04.09.2020 17:44 RM kirjutas: > } > I failed to find C++ regex tester in WWW, thus I don't know what's wrong > with my regex. Please help. This is more a regex question, not so much C++. I'm not a regex expert either, but when I tested your regex with normal egrep command-line, it seemed to work better when I used [\s\n] instead of (\s|\n). |
Jorgen Grahn <grahn+nntp@snipabacken.se>: Sep 06 08:30AM On Sun, 2020-09-06, Paavo Helde wrote: > 04.09.2020 17:44 RM kirjutas: ... >> I failed to find C++ regex tester in WWW, thus I don't know what's wrong >> with my regex. Please help. > This is more a regex question, not so much C++. It could be a C++ question if there was something unique about std::regex ... but the normal flavor of std::regex is ECMAScript, so an online Javascript regex tester should be good enough. Options like "multiline" most likely have direct equivalents, too. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
Brian Wood <woodbrian77@gmail.com>: Sep 05 06:59PM -0700 On Saturday, September 5, 2020 at 3:34:17 PM UTC-5, Mr Flibble wrote: > > can't kill the truth. I'd be happy to work with that > > prof. > That is because you are a bigot like him. I think we know who is the bigot here. It's not the professor and it's not me. |
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