- Why halt deciders can't be "interesting" programs. (HP refutation) - 2 Updates
- Why should a "c" programmer learn c++ ? - 4 Updates
- Why should a "c" programmer learn c++ ? (V2_a) - 10 Updates
| olcott <NoOne@NoWhere.com>: Sep 12 02:47PM -0500 On 9/12/2020 2:01 PM, Malcolm McLean wrote: > consist of a description of the principle on which your code works. But no > -one referee is going to inspect anything other than the simplest snippet of C > for errors. Referees simply don't have time. When-so-ever I submit anything less than 100% perfectly complete total proof (such as H actually deciding halting on H_Hat) in this forum everyone is so certain that I must be incorrect that they never bother to see that I am correct. > Now I don't believe that such a proof is possible. However I am still asking > for it because, as I have explained, it might be worth something to you if it > is sufficiently succinct and it looks superficially plausible. There is nothing more certain that a program sufficiently equivalent to H can decide halting on a program sufficiently equivalent to H_Hat than the actual program actually doing this. H returns a Boolean result and every step of the derivation of this Boolean result is provided. An execution trace is more reliable than a formal proof because proofs can have mistakes whereas actually executing code actually executes as it actually executes. > However if I can't spot an error in it, and no-one else here can point out an > error, then who are we to say that it is a fallacious proof? But we'll come > to that when we come to it. Yes my current goal is to have 100% complete results published (at least here) on the two year anniversary of my discovery: December 13, 2018 @ 7:00 PM. My plan for achieving this is to have everything totally complete 30 days from now, thus providing a two months safety margin to meet my anniversary date. The x86 based UTM equivalent seems totally complete except for this: Virtual Machine Instruction (operating system function call) // The master machine executes the slave machine void DebugStep(u32* master_state, u32* slave_state); All of the infrastructure for this including the every-single-detail design is in place, complete and passed testing. There was a bug with the COFF object file patch relocation code now fixed, and generalized to work with Microsoft assembly language and "C" generated COFF files. The code runs correctly on Microsoft and Linux. -- Copyright 2020 Pete Olcott |
| Richard Damon <Richard@Damon-Family.org>: Sep 12 06:57PM -0400 On 9/12/20 3:47 PM, olcott wrote: > There was a bug with the COFF object file patch relocation code now > fixed, and generalized to work with Microsoft assembly language and "C" > generated COFF files. The code runs correctly on Microsoft and Linux. Yes, if you can show a machine that does the following: Runs H(H^,H^) and returns a result. Runs H^(H^) which will run H(H^,H^) which will return the same result Then H^ either loops if H returned Halted, or Halts if H returned Loops And the result of H says H^(H^) halted if it does halt and loops if it does loop. Since if H say Halts, then H^ will loop, or if it says Loop it will Halt, it seems impossible to make H predict correctly if H^ works as required. SO there are basically 3 binary facts that are interesting, H(H^,H^) result, What H^(H^) did, and perhaps we will want what the copy of H inside H^ returned, |
| Bo Persson <bo@bo-persson.se>: Sep 12 08:46PM +0200 On 2020-09-12 at 15:23, Chris Vine wrote: > do better with some kind of Creative Commons licence for draft > documents - I notice that the "normal" drafts contain no copyright > notice at all. If you don't like the ISO legalese, you can try the document N4861 instead. It is a "working material", which doesn't have the ISO front cover, but is otherwise identical. |
| Bo Persson <bo@bo-persson.se>: Sep 12 08:49PM +0200 On 2020-09-12 at 20:46, Bo Persson wrote: > If you don't like the ISO legalese, you can try the document N4861 > instead. It is a "working material", which doesn't have the ISO front > cover, but is otherwise identical. And, BTW, it seems like N4860 has now been password protected, which it should probably have been from the beginning. :-) Bo Persson |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Sep 12 03:00PM -0700 Richard Damon <Richard@Damon-Family.org> writes: [...] > Another thing to consider is that despite what clause says, there are > implied "Fair Use" rights that people have, especially if the copyright > holder intentionally puts the document out on a public facing website. My limited understanding is that the Fair Use doctrine does not allow for distributing an entire work. Please don't take my work for this. "Fair Use" seems to be a widely misunderstood concept. I suggest that doing your own research or seeking out a forum where it's topical would be more productive that trying to discuss it here. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */ |
| Richard Damon <Richard@Damon-Family.org>: Sep 12 06:42PM -0400 On 9/12/20 6:00 PM, Keith Thompson wrote: > "Fair Use" seems to be a widely misunderstood concept. I suggest that > doing your own research or seeking out a forum where it's topical would > be more productive that trying to discuss it here. Yes, so by Fair use you can download and use if for yourself. If you want to give it to someone else, you give them the link to the ISO site and they can download it themselves. Note, the assumption is that placing the file on their server with a link that if you click on it will download the file to your computer implies that you give permission for people to down load it to their computer. |
| olcott <NoOne@NoWhere.com>: Sep 12 01:46PM -0500 On 9/12/2020 1:10 PM, Bonita Montero wrote: > for a certain capacity isn't touched until you add elements to the > vector. > So here's my gvector: You may have been able to simply add a custom allocator to std::vector to do the same thing. Here is an absolutely fabulous two-dimensional std::vector written by a member of this group: https://groups.google.com/forum/#!original/comp.lang.c++/OnNneMNMIoU/OvGbbA8vCakJ |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 12 08:57PM +0200 > You may have been able to simply add a custom allocator to std::vector > to do the same thing. How should that work ? There's no realloc-method of an allocator. The vector simply allocates new memory and copies it to the new allocated place. |
| Melzzzzz <Melzzzzz@zzzzz.com>: Sep 12 07:05PM > How should that work ? There's no realloc-method of an allocator. > The vector simply allocates new memory and copies it to the new > allocated place. Yep, one cannot copy verbatim without calling copy constructors, and destruct afterwards ... -- current job title: senior software engineer skills: c++,c,rust,go,nim,haskell... press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| olcott <NoOne@NoWhere.com>: Sep 12 02:13PM -0500 On 9/12/2020 1:57 PM, Bonita Montero wrote: > How should that work ? There's no realloc-method of an allocator. > The vector simply allocates new memory and copies it to the new > allocated place. https://stackoverflow.com/questions/11896960/custom-allocator-in-stdvector -- Copyright 2020 Pete Olcott |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 12 09:47PM +0200 >> The vector simply allocates new memory and copies it to the new >> allocated place. > https://stackoverflow.com/questions/11896960/custom-allocator-in-stdvector You're missing the point. As you can't grow a vector in-place with a custom allocator you can stick with my solution, which is simpler. |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 12 09:48PM +0200 >> https://stackoverflow.com/questions/11896960/custom-allocator-in-stdvector > You're missing the point. As you can't grow a vector in-place with > a custom allocator you can stick with my solution, which is simpler. And even more: an allocator can't manage the capacity of a vector. So having a custom allocator here doesn't make sense ! |
| olcott <NoOne@NoWhere.com>: Sep 12 02:57PM -0500 On 9/12/2020 2:48 PM, Bonita Montero wrote: >> a custom allocator you can stick with my solution, which is simpler. > And even more: an allocator can't manage the capacity of a vector. > So having a custom allocator here doesn't make sense ! I don't understand. The common memory growth factor of doubling the allocation on every reallocation does manage the std::vector::capacity() of the vector. -- Copyright 2020 Pete Olcott |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 12 10:02PM +0200 > I don't understand. The common memory growth factor of doubling the > allocation on every reallocation does manage the std::vector::capacity() > of the vector. You suggested doing what I did in the allocator. This would mean to allocate more memory than requested. But the vector wouldn't notice this. It simply assumes that it got no more memory than requested. So doing this growh like I did isn't possible through a custom allocator. |
| olcott <NoOne@NoWhere.com>: Sep 12 03:05PM -0500 On 9/12/2020 3:02 PM, Bonita Montero wrote: > notice this. It simply assumes that it got no more memory than > requested. So doing this growh like I did isn't possible through > a custom allocator. I am only referring to the std::vector::push_back() automatic reallocation memory growth factor. -- Copyright 2020 Pete Olcott |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 12 10:07PM +0200 > I am only referring to the std::vector::push_back() automatic > reallocation memory growth factor. No, you suggested to do what I did with a custom allocator: | You may have been able to simply add a custom allocator to | std::vector to do the same thing. That's not possible. |
| 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