- Concatenating strings efficiently - 7 Updates
- In template class, temporaries are substituted for [...] - 2 Updates
| Martijn van Buul <pino@dohd.org>: Oct 23 08:17AM * bitrex: > why am I implementing an encoding scheme for black and white television > on this test?!?!??!!? . ^^^^^^^^^ Maybe this is why: to test your response to things you don't appreciate. -- Martijn van Buul - pino@dohd.org |
| boltar@cylonhq.com: Oct 23 08:48AM On Tue, 23 Oct 2018 08:17:43 -0000 (UTC) >> on this test?!?!??!!? >.. ^^^^^^^^^ >Maybe this is why: to test your response to things you don't appreciate. More likely to test his ability to formulate an algorithm from scratch without just resorting to lego brick programming, ie slapping together APIs and frameworks developed by someone else. Any idiot can do the latter as millions of javascript and python programmers demonstrate every day. |
| "Öö Tiib" <ootiib@hot.ee>: Oct 23 03:44AM -0700 On Tuesday, 23 October 2018 11:17:55 UTC+3, Martijn van Buul wrote: > > on this test?!?!??!!? > . ^^^^^^^^^ > Maybe this is why: to test your response to things you don't appreciate. It could be fruitful to try to combine RLE into some real compression algorithm. For example as alternative for escaping totally transparent parts of image (or white parts of paper). Implementing it separately feels pointless in modern world where non-naive implementation of LZW is often quicker than memcpy. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Oct 23 07:54AM -0400 On 10/20/18 03:03, Ralf Goertz wrote: > Am 19 Oct 2018 19:36:30 GMT > schrieb Jorgen Grahn <grahn+nntp@snipabacken.se>: ... >> (Not that there's really a '\0' in any C string either; it's halfway >> there, halfway not. Traditionally, a fertile source of bugs.) > Is there not? I thought that's how strings are terminated in C. What he's referring to is the ambiguous status of the '\0'. For some purposes, it's part of the string. For other purposes, it's the part prior to the '\0' that is the actual string, the '\0' just lets you know where the string ends. This isn't actually ambiguous if you use clear terminology - which I deliberately failed to do in this message, to make the ambiguity clearer. However, it is actually necessary to be careful about such issues in order to avoid ambiguity, and it's that need to be careful which he's referring to. |
| bitrex <user@example.net>: Oct 23 12:40PM -0400 > just resorting to lego brick programming, ie slapping together APIs and > frameworks developed by someone else. Any idiot can do the latter as millions > of javascript and python programmers demonstrate every day. Poor bitrex has to formulate algorithm from scratch but interviewer gets to pull problem from Wikipedia. Hmph. I see how it is. |
| Christian Gollwitzer <auriocus@gmx.de>: Oct 23 09:54PM +0200 Am 23.10.18 um 12:44 schrieb Öö Tiib: > It could be fruitful to try to combine RLE into some real compression > algorithm. For example as alternative for escaping totally transparent > parts of image (or white parts of paper). Whenever you load or save a JPEG image, you use RLE compression, which is used as a pre-processor before Huffman entropy coding. I can barely think of another compression algorithm that is used as widely as JPEG, so it's not at all a 70's only concept. Christian |
| "Öö Tiib" <ootiib@hot.ee>: Oct 23 04:06PM -0700 On Tuesday, 23 October 2018 22:54:57 UTC+3, Christian Gollwitzer wrote: > is used as a pre-processor before Huffman entropy coding. I can barely > think of another compression algorithm that is used as widely as JPEG, > so it's not at all a 70's only concept. Yes, there it also packs zeroes. My point was that it is not useful alone but in combination with other compression algorithms be it statistics (like Huffman) or dictionary (like LZW). I actually already tried to express that but you considered it good idea to cut it in reply: "Implementing it separately feels pointless in modern world where non-naive implementation of LZW is often quicker than memcpy." |
| "Öö Tiib" <ootiib@hot.ee>: Oct 23 03:18AM -0700 On Sunday, 21 October 2018 21:58:24 UTC+3, Jorgen Grahn wrote: > picking simple (yet synthetic) examples and applying advanced > solutions may teach you to overdesign things which should be simple. > A technique is only good in a context where it's fitting. It is all correct but what we can suggest to Paul as good strategy for learning programming? My strategy was to make little useful tools to automate something tedious about my computer usage and other hobbies. However that was eighties when even most simple tools were often missing. Other idea can be to solve the problems on programming problem sites. There are countless such sites like Codeforces, GeeksforGeeks, CodeChef, LeetCode, HackerRank, TopCoder, CodinGame, CodeFights, Codewars, Coderbyte etc. That might help to see how bloat YAGNI "techniques" can make the result both complicated and inefficient. Are there some other ideas? May be reading a book or series like "Numerical Recipes"? I think there must always be some actual practical problem to solve. Without it any engineering turns into art of goalless patterns. > Yes. Why would it save memory? Nowadays it doesn't even avoid a > copy, since you can construct the Product straight into the > std::vector<Product>. He was apparently creating filtered vectors of pointers instead of doing range based for or for_each on original and filtering OTW. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 23 08:09PM On Tue, 2018-10-23, Öö Tiib wrote: > problem sites. There are countless such sites like Codeforces, > GeeksforGeeks, CodeChef, LeetCode, HackerRank, TopCoder, > CodinGame, CodeFights, Codewars, Coderbyte etc. I think that is a good idea. There are old threads in comp.lang.c++ on this subject (how to learn?) which are worth reading. I can't point to them though; last one I remember was a year or more ago. > like "Numerical Recipes"? I think there must always be some > actual practical problem to solve. Without it any engineering > turns into art of goalless patterns. +1 I have to add though that people are different. My programming improved a lot when I stopped trying to solve general problems, and began to focus on implementing one, concrete, useful thing. But I cannot say for sure it's like that for everyone. There's also the problem: if you haven't tried the less commonly useful and more advanced techniques, how do you know when to use them? Let others review the code, maybe. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| 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