| olcott <NoOne@NoWhere.com>: Mar 13 08:18AM -0600 On 3/13/2021 6:18 AM, Andy Walker wrote: > no idea what Jack will do but a few may know, most programs have > no idea what "H_Hat" will do but some may know [but they had > better not be claimed to be fully-correct halt deciders]. Jack is asked: Will your answer to this question be no? If Jack says no and bill says Jack will say no, Jack is wrong and Bill is right. If Jack says yes and Bill says Jack will say Yes, Jack is wrong and Bill is right. When-so-ever (for whatever reason) we have a yes/no (technically polar) question such that neither yes or no are the correct answer we have an incorrect question. Will H_Hat() halt on its input? is an incorrect question for Halts() because (just like Jack) both yes and no are the wrong answer. Would H_Hat() halt if the halt decider never stopped simulating it? Is the same question with the contradiction removed. Whenever any question defined such that both answers of yes and are contradicted the question is incorrect. Whenever decision problem input is defined such that both decisions of true and false are contradicted we have an incorrect decision problem/input instance. Whenever a new idea about an old problem is presented learned-by-rote people reject this new idea entirely on the basis that it does not conform to what they learned-by-rote. This is an utterly foolish thing to do. If an idea is to be rejected then the only legitimate basis to reject this idea is to find an error in it. Learned-by-rote people will still believe that they found the error in that it does not conform to what they learned by rote. Ben is a learned-by-rote person. -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| olcott <NoOne@NoWhere.com>: Mar 13 08:23AM -0600 On 3/13/2021 6:18 AM, Andy Walker wrote: > no idea what Jack will do but a few may know, most programs have > no idea what "H_Hat" will do but some may know [but they had > better not be claimed to be fully-correct halt deciders]. Jack is asked: Will your answer to this question be no? If Jack says no and bill says Jack will say no, Jack is wrong and Bill is right. If Jack says yes and Bill says Jack will say Yes, Jack is wrong and Bill is right. When-so-ever (for whatever reason) we have a yes/no (technically polar) question such that neither yes or no are the correct answer we have an incorrect question. Will H_Hat() halt on its input? is an incorrect question for Halts() because (just like Jack) both yes and no are the wrong answer. Would H_Hat() halt if the halt decider never stopped simulating it? Is the same question with the contradiction removed. Whenever any question defined such that both answers of yes and are contradicted the question is incorrect. Whenever decision problem input is defined such that both decisions of true and false are contradicted we have an incorrect decision problem/input instance. Whenever a new idea about an old problem is presented learned-by-rote people reject this new idea entirely on the basis that it does not conform to what they learned-by-rote. This is an utterly foolish thing to do. If an idea is to be rejected then the only legitimate basis to reject this idea is to find an error in it. Learned-by-rote people will still believe that they found the error in that it does not conform to what they learned by rote. Ben is a learned-by-rote person. -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| wij <wyniijj@gmail.com>: Mar 13 08:49AM -0800 On Wednesday, 10 March 2021 at 06:56:40 UTC+8, olcott wrote: > Copyright 2021 Pete Olcott > "Great spirits have always encountered violent opposition from mediocre > minds." Einstein There is no way to remove "the pathological self-reference", which you refer to as an error is also incorrect. Let S be a set of all non-halting programs. The ones that fit 'self-reference' are just a small subset of S. How you decide x is an element of S without simulating x is the problem. In this respect, your decider algorithm is still incomplele at most. Your posts are becoming annoying. |
| olcott <NoOne@NoWhere.com>: Mar 13 02:39PM -0600 On 3/13/2021 10:49 AM, wij wrote: > are just a small subset of S. > How you decide x is an element of S without simulating x is the problem. > In this respect, your decider algorithm is still incomplele at most. If you examine the execution trace on the least two pages of the above link you will see that it provides a 100% complete basis for Halts() to correctly decide that H_Hat() would not halt. -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| olcott <NoOne@NoWhere.com>: Mar 13 02:49PM -0600 On 3/13/2021 10:49 AM, wij wrote: >> minds." Einstein > There is no way to remove "the pathological self-reference", which you > refer to as an error is also incorrect. When the halting problem criteria is: Does the input program halt on its input? It is possible to define an input that does the opposite of whatever the halt decider decides. When the halting problem criteria is: Would the input program halt if the halt decider never stopped simulating it? Then any input that does the opposite of whatever the halt decider decides becomes decidable. The halt decider stops simulating this input on the basis that it is calling the halt decider in what would otherwise be infinite recursion then the halt decider reports that the input would not halt. -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| olcott <NoOne@NoWhere.com>: Mar 13 03:51PM -0600 On 3/13/2021 3:38 PM, Malcolm McLean wrote: > won't halt unless I halt it". > But H has got it wrong. You've got to somehow flag that the H-directed halt in > H_Hat doesn't count. No not true. The global halt decider is called on main() so both instances are correctly terminated because of what would otherwise be infinite recursion. When the halt decider is based on adapting a UTM then nothing can slip past the analysis of the halt decider. -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| olcott <NoOne@NoWhere.com>: Mar 13 04:09PM -0600 On 3/13/2021 4:00 PM, Malcolm McLean wrote: >> infinite recursion. > RIght, so the supervisor is placed outside of H, and it is this which decides the > halting / would not halt unless halted status of the program. When the Halt decider is based on a UTM then the halt decider is the supervisor of every computation. > You can't solve the halting problem this way, e.g. determine the halting > status of a famous unknown problem. However you can pick up tight loops > or simple infinite recursion. The "do the opposite of whatever the halt decider decides" of the conventional proofs becomes decidable, they are decided as would not halt. -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Mar 12 09:41PM -0800 >>> memory acquires the same effective type as the object it was copied from. >> Memory is memory, it doesn't have a type. > The C standard says otherwise, and so does the C++ standard. [...] Memory does not have a type. Objects have a type, but memory does not have a type. |
| scott@slp53.sl.home (Scott Lurndal): Mar 13 04:39PM >> The C standard says otherwise, and so does the C++ standard. [...] >Memory does not have a type. Objects have a type, but memory >does not have a type. A bit pedantic, perhaps. In the real world, memory does have a type. Non-cachable, cachable write-back or write-through, device with non-gathering/gathering, reordable/nonreorderable, early-return/non-early return semantics. Some programers need pay close attention to the memory type, even when using C++. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Mar 13 12:48PM -0500 >> The C standard says otherwise, and so does the C++ standard. [...] >Memory does not have a type. Objects have a type, but memory >does not have a type. An object is defined by the C standard as "region of data storage in the execution environment, the contents of which can represent values." If you don't see "memory" as valid alternative term for "region of data storage", I'm not going to argue the semantics of those terms with you - we generally have proven incapable of seeing eye-to-eye on such issues. Note that an object IS a region of data storage. The fact that the contents of that memory can represent values don't make it any less a piece of memory. It's just a piece of memory with which the implementation (may have) associated a particular type. |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Mar 12 10:33PM -0800 > I finally found a use for the `continue` statement, after some 25+ > years of C++. Also, learned that (apparently, but haven't really > tested) `std::optional` seems to be `constexpr`-compatible. Code: [lightly edited, mainly to avoid line wrapping] > where there is no arguably better alternative than using `continue`. > So, mainly because I don't see it, is there a better way to do that > failure handling, preferably without repeating oneself? I would probably write something like this: #include <stdexcept> using namespace std::literals; using Uint_128 = __uint128_t; inline constexpr Uint_128 operator""_u128( const char *input, unsigned long ){ using oops = std::runtime_error; auto combine = []( Uint_128 r, Uint_128 d ) -> Uint_128 { const Uint_128 minus_1 = -1, rh = minus_1 / 10, dh = minus_1 % 10; if( r > rh || r == rh && d > dh ){ throw oops( "Uint_128 value range exceeded for _u128 literal." ); } return r*10 + d; }; Uint_128 r = 0; for( const char *s = input; *s; s++ ){ if( '0' <= *s && *s <= '9' ) r = combine( r, *s - '0' ); else if( *s == '\'' ) { /* allow ' as separator */ } else throw oops( "Invalid character >"s + *s + "< in _u128 literal." ); } return r; } |
| 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