- Member operators - why the restriction? - 2 Updates
- Refuting the {Linz, Sipser, Kozen} HP Proofs - 4 Updates
- Advent of Code 2020 - Spoiler day 03 part A - 11 Updates
- Onwards and upwards - 1 Update
| Vir Campestris <vir.campestris@invalid.invalid>: Dec 10 09:07PM On 09/12/2020 11:36, Bonita Montero wrote: > I don't have to read again. A two parameter member-operator includes > the object as the left operand. So you can' define a member operator > with two parameters inside the class. And your answer to "Why the restriction?" is... |
| "Öö Tiib" <ootiib@hot.ee>: Dec 10 01:54PM -0800 On Thursday, 10 December 2020 at 23:08:10 UTC+2, Vir Campestris wrote: > > the object as the left operand. So you can' define a member operator > > with two parameters inside the class. > And your answer to "Why the restriction?" is... I suspect it is not restriction but syntax how free operators and member operators are declared. Member operators have first hidden parameter as this like member functions have first hidden parameter as this. Type of operators what you want is not part of language. It could be added like for example static member operators ... but no one has seemingly pushed such ideas hard enough. |
| olcott <NoOne@NoWhere.com>: Dec 09 10:16PM -0600 On 12/9/2020 10:35 AM, Ben Bacarisse wrote: > same argument. Either "runaway recursion" will exclude many > computations that need to be halted, or it will incorrectly include many > that are about to halt in their own. When a master UTM simulates the {Linz, Sipser, Kozen} counter-example it terminates them because of infinite recursion before they every receive any return value. // Ben Bacarisse from comp.theory void Confound_Halts(u32 P) { if (Halts(P, P)) while (1); } int main() { HERE: goto HERE; Confound_Halts((u32)Confound_Halts); Halts((u32)Confound_Halts, (u32)Confound_Halts); } From the perspective of this master UTM all three lines of main() specify infinite execution. // Michael Sipser u32 D(u32 P) { u32 Input_Halts = Halts(P, P); if (Input_Halts) return 0; // Indicating not halts else return 1; // Indicating halts } http://www.liarparadox.org/sipser_165.pdf Sipser, Michael 1997. Introduction to the Theory of Computation. Boston: PWS Publishing Company (165-167) http://www.liarparadox.org/kozen_233.pdf The Kozen computation is identical to the Peter Linz computation merely swapping function names Linz.H is swapped for Kozen.K and Linz.Ĥ is swapped for Kozen.N Kozen, Dexter 1997. Automata and Computability. New York: Springer-Verlag. (231-234). -- Copyright 2020 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| olcott <NoOne@NoWhere.com>: Dec 10 08:49AM -0600 On 12/10/2020 5:41 AM, Ben Bacarisse wrote: >> recursion. > A ridiculously trivial claim. You really need to take care with your > language. You are a master of deception of avoiding the point: Stop baselessly disparaging me and my work. Point out an error in the following or admit that you cannot because there are none. On 11/27/2020 9:02 PM, Ben Bacarisse wrote: > A computation that would not halt if its simulation were not > halted is indeed a non-halting computation. On Saturday, November 28, 2020 at 2:00:28 PM UTC-8, olcott wrote: > Every computation that would not halt if its simulation > were not halted is by logical necessity a non-halting computation. The following is shown to be decided on the basis of the above criteria: This input to the Microsoft C compiler produces a COFF object file that is directly emulated by an x86 emulator. void Confound_Halts(u32 P) { if (Halts(P, P)) while (1); } #define HALT __asm hlt int main() { Confound_Halts((u32)Confound_Halts); HALT; } _Confound_Halts() [0000063c](01) 55 push ebp [0000063d](02) 8bec mov ebp,esp [0000063f](03) 8b4508 mov eax,[ebp+08] [00000642](01) 50 push eax [00000643](03) 8b4d08 mov ecx,[ebp+08] [00000646](01) 51 push ecx [00000647](05) e800feffff call 0000044c [0000064c](03) 83c408 add esp,+08 [0000064f](02) 85c0 test eax,eax [00000651](02) 740b jz 0000065e [00000653](05) ba01000000 mov edx,00000001 [00000658](02) 85d2 test edx,edx [0000065a](02) 7402 jz 0000065e [0000065c](02) ebf5 jmp 00000653 [0000065e](01) 5d pop ebp [0000065f](01) c3 ret _main() [0000066c](01) 55 push ebp [0000066d](02) 8bec mov ebp,esp [0000066f](05) 683c060000 push 0000063c [00000674](05) e8c3ffffff call 0000063c [00000679](03) 83c404 add esp,+04 [0000067c](01) f4 hlt [0000067d](01) 5d pop ebp [0000067e](01) c3 ret Output_Debug_Trace() Trace_List.size(17) [0000066c](01) 55 push ebp [0000066d](02) 8bec mov ebp,esp [0000066f](05) 683c060000 push 0000063c [00000674](05) e8c3ffffff call 0000063c // CALL Confound_Halts() [0000063c](01) 55 push ebp [0000063d](02) 8bec mov ebp,esp [0000063f](03) 8b4508 mov eax,[ebp+08] [00000642](01) 50 push eax [00000643](03) 8b4d08 mov ecx,[ebp+08] [00000646](01) 51 push ecx [00000647](05) e800feffff call 0000044c // CALL Halts() [0000063c](01) 55 push ebp [0000063d](02) 8bec mov ebp,esp [0000063f](03) 8b4508 mov eax,[ebp+08] [00000642](01) 50 push eax [00000643](03) 8b4d08 mov ecx,[ebp+08] [00000646](01) 51 push ecx [00000647](05) e800feffff call 0000044c // CALL Halts() The PRIOR Instruction Specifies Infinite Recursion: Simulation Stopped: Every time that the same function is called from the same machine address a second time without any control flow instructions in-between is a case of infinite recursion. This is shown at execution trace lines 12-19 above. -- Copyright 2020 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| olcott <NoOne@NoWhere.com>: Dec 10 09:35AM -0600 On 12/10/2020 9:18 AM, André G. Isaak wrote: >>> doesn't even remotely address my objection above. >> A code trace <is> a formal proof of the execution of the x86 language. > No, a code trace is not a formal proof of anything. A code trace is a totally complete proof of what the code actually does on its input. > calls. You just don't show them. There must be because your 'halt > detector' makes a decision as to whether to abort at any given call. > That involves a conditional branch. THE MOST IMPORTANT WORDS THAT I HAVE EVER SAID ON THIS SUBJECT: THE MOST IMPORTANT WORDS THAT I HAVE EVER SAID ON THIS SUBJECT: THE MOST IMPORTANT WORDS THAT I HAVE EVER SAID ON THIS SUBJECT: All conditional branches that are in the halt decider and not in the user code can be correctly ignored within the context of the following halt deciding criteria: Notice the future tense of: [would not halt] On 11/27/2020 9:02 PM, Ben Bacarisse wrote: > A computation that would not halt if its simulation were not > halted is indeed a non-halting computation. On Saturday, November 28, 2020 at 2:00:28 PM UTC-8, olcott wrote: >>> are not deriving your H_Hat from your halt decider correctly. > No comment on the above? > André I already addressed what you said. -- Copyright 2020 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| olcott <NoOne@NoWhere.com>: Dec 10 10:11AM -0600 On 12/10/2020 9:55 AM, André G. Isaak wrote: > piece of software does. It doesn't in any way demonstrate that the > results it produces are correct (i.e. produce the correct result for the > problem the software purports to solve). The execution trace does prove that it applied its criteria to its input correctly. >> user code can be correctly ignored within the context of the following >> halt deciding criteria: > That is simply false, no matter how many times you repeat it. There are two steps to proving that that my statement is correct: (1) Verifying that this is correct halt deciding criteria. (2) Verifying that the input meets this criteria. On 11/27/2020 9:02 PM, Ben Bacarisse wrote: > A computation that would not halt if its simulation were not > halted is indeed a non-halting computation. On Saturday, November 28, 2020 at 2:00:28 PM UTC-8, olcott wrote: > Every computation that would not halt if its simulation > were not halted is by logical necessity a non-halting computation. The only reason that people believe that I am incorrect is that they never bothered to verify the above two steps. -- Copyright 2020 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Dec 10 07:06AM > Everyone is different I suppose. I disagree completely - I find a screen full > of std:: everywhere is just useless visual noise and clutter that detracts from > being able to read the code You won't see std:: everywhere though. Juha might have mentioned it upthread, but there won't be as many as you'd think. At least that's how it felt to me when I stopped using 'using namespace std'. Try it on a piece of code you already have, and see. Or read someone else's code. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| spuddy@isnotyourbuddy.co.uk: Dec 10 08:44AM On 10 Dec 2020 07:06:00 GMT >how it felt to me when I stopped using 'using namespace std'. >Try it on a piece of code you already have, and see. Or read someone >else's code. Thats the problem , I spend huge amounts of time working on other peoples code that is littered with std:: all over the damn place that adds zero to readability for me. If I can I usually do :s/std:://g and be done with it. |
| spuddy@isnotyourbuddy.co.uk: Dec 10 08:45AM On Wed, 9 Dec 2020 13:19:32 -0500 >decide if this is referring to a local concept or some global standard one. >If I see just string, does my local namespace provide an enhanced >version, or is this the standard one. Not a problem I've ever encountered. |
| Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk>: Dec 10 10:20AM > If I can I usually do :s/std:://g and be done with it. Totally irrational, take your meds. /Flibble -- 😎 |
| Juha Nieminen <nospam@thanks.invalid>: Dec 10 11:05AM >>are being used. Without the prefix it requires a deeper look, and a deeper >>experience and knowledge of what's from the standard library and what isn't. > Everyone is different I suppose. I disagree completely You disagree completely... So absolutely nothing of what I wrote you agree with. Not a single point or detail. When you see even the most obscure and least-used standard library names being used, you immediately recognize it as a standard library name with a quick visual scan, and immediately know what it does. When you see something like "if(equal(a, b, c))" you immediately think "of course it's the equal() function in the standard library! What else could it possibly be? It can't be anything else!" When you see name like "kill_dependency", or "perm_options", or "exists", or "gamma_distribution" in a piece of code, you immediately know that they are from the standard library. No need to guess or look further! Some time in the past in another forum someone tried to prove how unreadable code becomes when using the std:: prefix and wrote a piece of code of a few lines in length that deliberately had as many uses of standard library names as possible, and compared it to not using the prefix. Ironically, I found the version with the prefixes a lot easier to read and understand because of all the visual clues that the prefix was giving me. |
| spuddy@isnotyourbuddy.co.uk: Dec 10 11:11AM On Thu, 10 Dec 2020 10:20:53 +0000 >On 10/12/2020 08:44, spuddy@isnotyourbuddy.co.uk wrote: >> If I can I usually do :s/std:://g and be done with it. >Totally irrational, take your meds. I doubt you even know what thats refering to Windows Guy. |
| spuddy@isnotyourbuddy.co.uk: Dec 10 11:42AM On Thu, 10 Dec 2020 11:05:17 +0000 (UTC) >> Everyone is different I suppose. I disagree completely >You disagree completely... So absolutely nothing of what I wrote you agree >with. Not a single point or detail. Don't split hairs, you know what I meant. An experience developer shouldn't need std:: nor care what is being used from the STL. How does that make debugging any easier? >When you see even the most obscure and least-used standard library names >being used, you immediately recognize it as a standard library name with >a quick visual scan, and immediately know what it does. When you see No, it just gets lost in a sea of :: >When you see name like "kill_dependency", or "perm_options", or "exists", >or "gamma_distribution" in a piece of code, you immediately know that they >are from the standard library. No need to guess or look further! Who cares? If they're obscure parts of the STL you won't know what they do anyway so knowing they're from the STL makes no difference since sticking them in google will tell you all you need to know. >the prefix. Ironically, I found the version with the prefixes a lot >easier to read and understand because of all the visual clues that >the prefix was giving me. As I said, each to their own. That simply demostrates your personal psychology, not whether code is readable. |
| Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk>: Dec 10 12:05PM >>> If I can I usually do :s/std:://g and be done with it. >> Totally irrational, take your meds. > I doubt you even know what thats refering to Windows Guy. It means you are doing a search/replace of "std::" with "" and unlike you I use a variety of POSIX-compliant operating systems as well Windows (not sure if Windows 10 is currently POSIX-compliant), Fucktarded Guy. So, again, irrational, take your meds. /Flibble -- 😎 |
| Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk>: Dec 10 12:07PM >> the prefix was giving me. > As I said, each to their own. That simply demostrates your personal psychology, > not whether code is readable. Your personal psychology is that of the irrational kind, mate. /Flibble -- 😎 |
| spuddy@isnotyourbuddy.co.uk: Dec 10 12:37PM On Thu, 10 Dec 2020 12:05:54 +0000 >use a variety of POSIX-compliant operating systems as well Windows (not sure >if Windows 10 is currently POSIX-compliant), Fucktarded Guy. >So, again, irrational, take your meds. I see youre up to your usual level of debate. |
| Richard Damon <Richard@Damon-Family.org>: Dec 10 08:02AM -0500 > Who cares? If they're obscure parts of the STL you won't know what they do > anyway so knowing they're from the STL makes no difference since sticking > them in google will tell you all you need to know. But you at least know where to look for the description. The std:: prefix bdcomes useful when the program grows bigger than you can hold most of its parts description in your head at once. Before you hit that point, the std:: may seem to be 'noise', but once the program passes that point, it become essential 'signal' to help with understanding. |
| "Öö Tiib" <ootiib@hot.ee>: Dec 09 04:57PM -0800 > Quality software is hard to produce and getting more so > with Corona/Wuhan. Sorry, but for those outside the ark, > prospects are bleak. I do not even understand what you are saying. Usefulness of software cannot be replaced with issue of financial, political, racial, sexual, religious and/or medical conditions of authors. They need modules made by me to work well not what I think or don't think of Hillary Clinton. |
| 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