| olcott <NoOne@NoWhere.com>: Dec 01 09:13AM -0600 On 12/1/2020 6:00 AM, Malcolm McLean wrote: > The halt decider doesn't have to handle every case, and it doesn't have to > work for the infinite possible variations on the H_Hat theme. You just > need one counter-example and the proof falls. Bingo !!! Thanks for your support !!! -- Copyright 2020 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| olcott <NoOne@NoWhere.com>: Dec 01 09:33AM -0600 On 12/1/2020 9:22 AM, Andy Walker wrote: > problem", as any fule kno.*] > ____ > * https://en.wikipedia.org/wiki/Nigel_Molesworth Here is another choice from fully operational code. The only way that you can maintain your false believe that I am incorrect is to make sure to not pay attention to the following complete execution trace of fully operational code. void H_Hat(u32 P) { u32 Aborted = DebugTrace(P, P); if (Aborted) HALT else HERE: goto HERE; } int main() { DebugTrace((u32)H_Hat, (u32)H_Hat); HALT; } _H_Hat() [00000584](01) 55 push ebp [00000585](02) 8bec mov ebp,esp [00000587](01) 51 push ecx [00000588](03) 8b4508 mov eax,[ebp+08] [0000058b](01) 50 push eax [0000058c](03) 8b4d08 mov ecx,[ebp+08] [0000058f](01) 51 push ecx [00000590](05) e8bffdffff call 00000354 [00000595](03) 83c408 add esp,+08 [00000598](03) 8945fc mov [ebp-04],eax [0000059b](04) 837dfc00 cmp dword [ebp-04],+00 [0000059f](02) 7403 jz 000005a4 [000005a1](01) f4 hlt [000005a2](02) eb02 jmp 000005a6 [000005a4](02) ebfe jmp 000005a4 [000005a6](02) 8be5 mov esp,ebp [000005a8](01) 5d pop ebp [000005a9](01) c3 ret _main() [000005b4](01) 55 push ebp [000005b5](02) 8bec mov ebp,esp [000005b7](05) 6884050000 push 00000584 [000005bc](05) 6884050000 push 00000584 [000005c1](05) e88efdffff call 00000354 [000005c6](03) 83c408 add esp,+08 [000005c9](01) f4 hlt [000005ca](01) 5d pop ebp [000005cb](01) c3 ret Output_Debug_Trace() [00010bd3] size(80) capacity(65536) [000005b4](01) 55 push ebp [000005b5](02) 8bec mov ebp,esp [000005b7](05) 6884050000 push 00000584 [000005bc](05) 6884050000 push 00000584 [000005c1](05) e88efdffff call 00000354 ----CALL [00000354] [00000584](01) 55 push ebp [00000585](02) 8bec mov ebp,esp [00000587](01) 51 push ecx [00000588](03) 8b4508 mov eax,[ebp+08] [0000058b](01) 50 push eax [0000058c](03) 8b4d08 mov ecx,[ebp+08] [0000058f](01) 51 push ecx [00000590](05) e8bffdffff call 00000354 ----CALL [00000354] [00000584](01) 55 push ebp [00000585](02) 8bec mov ebp,esp [00000587](01) 51 push ecx [00000588](03) 8b4508 mov eax,[ebp+08] [0000058b](01) 50 push eax [0000058c](03) 8b4d08 mov ecx,[ebp+08] [0000058f](01) 51 push ecx [00000590](05) e8bffdffff call 00000354 ----CALL [00000354] The PRIOR Instruction Specifies Infinite Recursion: Simulation Stopped: -- Copyright 2020 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| Kaz Kylheku <563-365-8930@kylheku.com>: Dec 01 06:14PM > void H_Hat(u32 P) This program has issues. > { > u32 Aborted = DebugTrace(P, P); The assumption is that DebugTrace always terminates, in one of two ways. If it returns nonzero, it means that the termination was forced by the simulator, otherwise zero means that P(P) spontaneously halted. The nonzero case can be a false positive, arising from DebugTrace simply not having run P(P) long enough for it to terminate. The essence of the halting problem is that the decider runs into situations in which it itself does not terminate and those are the big problem. You essentially are begging the question: you're *assuming* that your halting decider will always terminate, and therefore arguing that the proofs are wrong because your decider terminates. > { > DebugTrace((u32)H_Hat, (u32)H_Hat); > HALT; Since DebugTrace always terminates, we always reach HALT. Well, what is the meaning of that? This program is supposed to report whether something halted or not; where is it doing that? Why are we ignoring the return value of DebugTrace here? It seems that we can substitute any arguments whatsoever in the DebugTrace call and the program reports the same termination status; how is that a decider? The above are all serious flaws in your work. |
| olcott <NoOne@NoWhere.com>: Dec 01 12:37PM -0600 On 12/1/2020 12:14 PM, Kaz Kylheku wrote: > DebugTrace call and the program reports the same termination status; how > is that a decider? > The above are all serious flaws in your work. Currently the halt decider is implemented at the operating system level so that it correctly decides these non halting cases: int main() { HERE: goto HERE; OutputString("Hello World!"); HALT; } Output_Debug_Trace() [00010be8] size(12) capacity(65536) [000005c4](01) 55 push ebp [000005c5](02) 8bec mov ebp,esp [000005c7](02) ebfe jmp 000005c7 ---- JMP [000005c7] [000005c7](02) ebfe jmp 000005c7 ---- JMP [000005c7] The PRIOR Instruction Specifies an Infinite Loop: Simulation Stopped: HERE: goto HERE; H_Hat((u32)H_Hat); HALT; } Output_Debug_Trace() [00010bc4] size(76) capacity(65536) [000005b4](01) 55 push ebp [000005b5](02) 8bec mov ebp,esp [000005b7](05) 6884050000 push 00000584 [000005bc](05) e8c3ffffff call 00000584 ----CALL [00000584] [00000584](01) 55 push ebp [00000585](02) 8bec mov ebp,esp [00000587](01) 51 push ecx [00000588](03) 8b4508 mov eax,[ebp+08] [0000058b](01) 50 push eax [0000058c](03) 8b4d08 mov ecx,[ebp+08] [0000058f](01) 51 push ecx [00000590](05) e8bffdffff call 00000354 ----CALL [00000354] [00000584](01) 55 push ebp [00000585](02) 8bec mov ebp,esp [00000587](01) 51 push ecx [00000588](03) 8b4508 mov eax,[ebp+08] [0000058b](01) 50 push eax [0000058c](03) 8b4d08 mov ecx,[ebp+08] [0000058f](01) 51 push ecx [00000590](05) e8bffdffff call 00000354 ----CALL [00000354] The PRIOR Instruction Specifies Infinite Recursion: Simulation Stopped: -- Copyright 2020 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| olcott <NoOne@NoWhere.com>: Dec 01 03:49PM -0600 On 12/1/2020 3:30 PM, Kaz Kylheku wrote: > You must make the strongest possible interpretation of this. > For instance, H_Hat can invoke Halts using a tamper-proof virtual > machine of its own. I only have to find one case of the conventional halting problem proof "do the opposite of whatever the halt decider decides" to refute all of these proofs. Malcolm understands this: On 12/1/2020 6:00 AM, Malcolm McLean wrote: > doesn't have to > work for the infinite possible variations on the H_Hat theme. You just > need one counter-example and the proof falls. I DO NOT HAVE TO SOLVE THE HALTING PROBLEM TO REFUTE THE CONVENTIONAL PROOFS. -- Copyright 2020 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| "The Doctor" <doctor@doctor.nl2k.ab.ca>: Dec 01 03:01PM XanaNews Statistic for comp.lang.c++. 12/1/2020 8:01:08 AM From article 419204 (11/1/2020 5:55:15 AM) to article 419540 (11/30/2020 1:53:49 PM) Number of threads ................... 34 Number of articles .................. 341 Average articles per thread ......... 10.03 Number of unanswered posts .......... 12 Number of posts from XanaNews users .. 1 Top Threads Ranking Articles Subject ------- -------- ---------------------------------- 1 57 Is bool no longer a primitive data type of C/C++ ? 2 40 "C++ programming language: How it became the invisible foundation for everything, and what's next" 3 36 std::sort slow due to allocating and deallocing memory? 4 34 Re: C++20 Designated initializers + struct member initializer 5 30 Re: Onwards and upwards 6 22 arranging items in a array with a sorted pointer-list 7 22 Re: A non-halting decider is defined 8 14 Re: About my new software product and about artificial intelligence.. 9 13 Is there a way to list all supported locales either the C- or C++-runtime? 10 12 Re: New Lightweight C++ Logging Framework 11 9 Minimum time for bruteforce 12 8 Re: T const 13 7 Re: std::getline( basic_istream<...> &&input, basic_string<...> &str ) 14 5 Services - singletons reinvented 15 3 Halts() correctly decides the conventional counter-example of the HP proofs 16 3 Re: Hashing for unordered containers? 17 3 Happy Thanksgiving to all 18 3 It is known that a correct halt decider must return false (in this case)[V4](Linz) 19 2 Re: More explanation of my poem of Love 20 2 It is known that a correct halt decider must return false (in this case)[V3] 21 2 Re: Why should a "c" programmer learn c++ ? (V2) 22 2 Re: The key aspects of x86utm are now finally complete (Refuting the HP proofs)(39 days of review and no mistakes found) Top Posters Ranking Articles Name Most Used Newsreader ------- -------- -------------------------- -------------------- 1 35 Bonita Montero Mozilla 2 27 olcott Mozilla 3 27 Mr Flibble Mozilla 4 23 David Brown Mozilla 5 18 Juha Nieminen tin 6 16 Öö Tiib G2 7 16 Brian Wood G2 8 13 Tim Rentsch Gnus 9 13 Christian Hanné Mozilla 10 11 Melzzzzz slrn 11 9 Jorgen Grahn slrn 12 9 Scott Lurndal xrn 13 9 Chris M. Thomasson Mozilla 14 9 Philipp Klaus Krause Mozilla 15 8 Richard Damon Mozilla 16 7 James Kuyper Mozilla 17 7 Alf P. Steinbach Mozilla 18 7 Rick C. Hodgin G2 19 6 Amine Moulay Ramdane G2 20 6 Tim Woodall slrn 21 6 daniel...@gmail.com G2 22 6 Keith Thompson Gnus 23 5 Ian Collins Mozilla 24 4 Lynn McGuire Mozilla 25 4 red floyd Mozilla 26 4 Kaz Kylheku slrn 27 3 Richard trn 28 3 Bo Persson Mozilla 29 3 Leo Mozilla 30 2 Vir Campestris Mozilla 31 2 Siri Cruise MT-NewsWatcher 32 2 Joe Pfeiffer Gnus 33 2 Frederick Gotham G2 34 2 Sjouke Burry Mozilla 35 1 Chris Vine Sylpheed 36 1 Manfred Mozilla 37 1 Christian Gollwitzer Mozilla 38 1 The Doctor XanaNews 39 1 Paavo Helde Mozilla 40 1 Nikolaj Lazic slrn 41 1 Ben Bacarisse 42 1 Mike Terry Mozilla 43 1 Bart Mozilla 44 1 Nikki Locke Nikkis auto poster 45 1 F Russell Pan 46 1 Pankaj Jangid Gnus 47 1 see.my....@gmail.com G2 Top Newsreaders Ranking Articles Newsreader Users ------- -------- -------------------------------------------- ----- 1 195 Mozilla 23 2 52 G2 7 3 31 slrn 5 4 22 Gnus 4 5 18 tin 1 6 9 xrn 1 7 3 trn 1 8 2 MT-NewsWatcher 1 9 1 Pan 1 10 1 <unknown> 1 11 1 Sylpheed 1 12 1 XanaNews 1 13 1 Nikkis auto poster 1 -- This email has been checked for viruses by AVG. https://www.avg.com |
| Vir Campestris <vir.campestris@invalid.invalid>: Dec 01 12:48PM I'm trying to unpick some copy-paste inheritance, and I've just bumped into a nasty. In three of the copied files there are identical operator<< and operator>> for a data type which isn't the class - it's something it holds. In the fourth one the operator>> and << is different (it's the one called "Legacy"). What I'd _like_ to do is to have a member operator<< in the base class, and override it in the legacy one. But I can't. Member operator<< can only be for the object itself, not some other type. Anybody know why? Andy |
| Bo Persson <bo@bo-persson.se>: Dec 01 03:24PM +0100 On 2020-12-01 at 13:48, Vir Campestris wrote: > Member operator<< can only be for the object itself, not some other type. > Anybody know why? > Andy It's not specific to operator<<, but all member operators are treated as having an extra 'this' parameter. It's used in overload resolution to select the proper one to call. So if you write a member operator<< with two other parameter types, the compiler will treat it as having 3 parameters. Non-members will most often come to the rescue here. Bo Persson |
| 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