Re: replaceFirst, findPieces, and takeExactly
On 01/23/2011 06:21 AM, Andrei Alexandrescu wrote: On 1/22/11 10:59 PM, Jonathan M Davis wrote: This will be a _fantastic_ function to have. I think that I probably even have an enhancement request somewhere that includes such a function. It's far too common that you have to find something and you want both what is before and after the point that you find. Now, that being the case, I'd probably more commonly find it useful to get the part before what was found and then the part beginning with what was found, but this works too. I suspect there might be a simple and intuitive way to define a family of functions that give you whatever portions of the find you're interested in (before, match, after, before and match, match and after). That could be either a naming convention or a template argument. Any ideas, let me know. Andrei Guess (tell me if I'm wrong) english says cut into pieces. Thus, I would consider a paradigm starting with either cut- or piece-/pieces-. Side-note I still find that find- (!) is wrong for funcs like findParts, even knowing the current find function actually returns the part match-and-after. Actually, it's find trying to do too much imo, should just return the (first) match; what anybody else would expect, or what? Thus, the name does not fit, the semantics is unexpected, and weird errors are to come. auto bigNumber = find!(a10)(numbers); // too bad! // Next applicant, please ;-) Note I'm not at all against Andrei's generalised algos --on the contrary. But having them too smart at the price of beeing counter-intuitive is wrong imo. /Side-note Denis _ vita es estrany spir.wikidot.com
Re: replaceFirst, findPieces, and takeExactly
On 1/23/11 1:22 AM, Jim wrote: Andrei Alexandrescu Wrote: I suspect there might be a simple and intuitive way to define a family of functions that give you whatever portions of the find you're interested in (before, match, after, before and match, match and after). That could be either a naming convention or a template argument. Any ideas, let me know. splitAt splitBefore splitAfter ? That's a good suggestion, thanks. One issue is that if the element type of the range is integral, there is confusion (did you mean to split at position k?). I decided to go with these: http://d-programming-language.org/cutting-edge/phobos/std_algorithm.html#findSplit Andrei
Re: replaceFirst, findPieces, and takeExactly
On Sunday 23 January 2011 07:12:34 Andrei Alexandrescu wrote: On 1/23/11 1:22 AM, Jim wrote: Andrei Alexandrescu Wrote: I suspect there might be a simple and intuitive way to define a family of functions that give you whatever portions of the find you're interested in (before, match, after, before and match, match and after). That could be either a naming convention or a template argument. Any ideas, let me know. splitAt splitBefore splitAfter ? That's a good suggestion, thanks. One issue is that if the element type of the range is integral, there is confusion (did you mean to split at position k?). I decided to go with these: http://d-programming-language.org/cutting-edge/phobos/std_algorithm.html#fi ndSplit That definitely seems like a good solution. - Jonathan M Davis
Re: replaceFirst, findPieces, and takeExactly
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:ihfm34$jvb$1...@digitalmars.com... On 1/22/11 4:16 PM, bearophile wrote: Andrei: Back then people said that STL's find() is better than D's find() because the former returns an iterator that can be combined with either the first iterator to get the portion before the match, or with the last iterator to get the portion starting at the match. D's find() only gives you the portion after the match. There's a HUGE problem here. This equivalence is sometimes true, but surely not always true: more powerful != better That function allows you to pick a determined number of elements from a range, assuming the range is never shorter than that. That sounds a bit obscure, but plays a pivotal role in findParts() (which is the name I settled on for the equivalent of Python's partition()): trisect is way better than findParts :-) And it's a single word with no uppercase letters in the middle. There is still time until the next release. Votes for trisect? vote-- findParts is the sort of thing that once you read what it does just *once*, it immediately becomes both obvious and easy to remember. But trisect is 1. scary, 2. I'd never remember it, and 3. Whenever I'd come across it, I'd never remember what it meant. Those are paricularly bad since I know right now I'm going to find it an incredibly useful function: There's already been too many times I've written this mess and felt dirty about it: auto result = find(str, delim); auto firstPart = str[0..$-result.length]; So I'm thrilled to see this function being added.
Re: replaceFirst, findPieces, and takeExactly
On 1/22/11 5:14 PM, Nick Sabalausky wrote: Andrei Alexandrescuseewebsiteforem...@erdani.org wrote in message news:ihfm34$jvb$1...@digitalmars.com... On 1/22/11 4:16 PM, bearophile wrote: Andrei: Back then people said that STL's find() is better than D's find() because the former returns an iterator that can be combined with either the first iterator to get the portion before the match, or with the last iterator to get the portion starting at the match. D's find() only gives you the portion after the match. There's a HUGE problem here. This equivalence is sometimes true, but surely not always true: more powerful != better That function allows you to pick a determined number of elements from a range, assuming the range is never shorter than that. That sounds a bit obscure, but plays a pivotal role in findParts() (which is the name I settled on for the equivalent of Python's partition()): trisect is way better than findParts :-) And it's a single word with no uppercase letters in the middle. There is still time until the next release. Votes for trisect? vote-- findParts is the sort of thing that once you read what it does just *once*, it immediately becomes both obvious and easy to remember. But trisect is 1. scary, 2. I'd never remember it, and 3. Whenever I'd come across it, I'd never remember what it meant. Those are paricularly bad since I know right now I'm going to find it an incredibly useful function: There's already been too many times I've written this mess and felt dirty about it: auto result = find(str, delim); auto firstPart = str[0..$-result.length]; So I'm thrilled to see this function being added. Yes, I'm absolutely in agreement with the naming (and thrilled too). I imagine a putative user looking through std.algorithm (let's see... what find functions are out there?). That makes findPieces easy to get to, whereas trisect would be oddly situated in the alphabetic list and oddly named enough to be virtually undiscoverable. Andrei
Re: replaceFirst, findPieces, and takeExactly
Andrei Alexandrescu napisał: On 1/22/11 5:14 PM, Nick Sabalausky wrote: Andrei Alexandrescuseewebsiteforem...@erdani.org wrote in message news:ihfm34$jvb$1...@digitalmars.com... On 1/22/11 4:16 PM, bearophile wrote: Andrei: Back then people said that STL's find() is better than D's find() because the former returns an iterator that can be combined with either the first iterator to get the portion before the match, or with the last iterator to get the portion starting at the match. D's find() only gives you the portion after the match. There's a HUGE problem here. This equivalence is sometimes true, but surely not always true: more powerful != better That function allows you to pick a determined number of elements from a range, assuming the range is never shorter than that. That sounds a bit obscure, but plays a pivotal role in findParts() (which is the name I settled on for the equivalent of Python's partition()): trisect is way better than findParts :-) And it's a single word with no uppercase letters in the middle. There is still time until the next release. Votes for trisect? vote-- findParts is the sort of thing that once you read what it does just *once*, it immediately becomes both obvious and easy to remember. But trisect is 1. scary, 2. I'd never remember it, and 3. Whenever I'd come across it, I'd never remember what it meant. Those are paricularly bad since I know right now I'm going to find it an incredibly useful function: There's already been too many times I've written this mess and felt dirty about it: auto result = find(str, delim); auto firstPart = str[0..$-result.length]; So I'm thrilled to see this function being added. Yes, I'm absolutely in agreement with the naming (and thrilled too). I imagine a putative user looking through std.algorithm (let's see... what find functions are out there?). That makes findPieces easy to get to, whereas trisect would be oddly situated in the alphabetic list and oddly named enough to be virtually undiscoverable. Me a tad less, but not because of the name. I'd still rather see a lazy range of pre-hit-post tuples. Am I the only one to see findParts as a no-patterns variation of RegexMatch accepting all element types, not just char? Then even the name comes naturally -- match. -- Tomek
Re: replaceFirst, findPieces, and takeExactly
Yes, I'm absolutely in agreement with the naming (and thrilled too). I imagine a putative user looking through std.algorithm (let's see... what find functions are out there?). That makes findPieces easy to get to, whereas trisect would be oddly situated in the alphabetic list and oddly named enough to be virtually undiscoverable. If this is the reasoning. This is a split function, not a find. There will be a few more of these split functions i suppose and this is the reason of my proposal splitAt. It is in the definition of the function you quoted. (Split) the string (at) the first occurrence of (sep) splitAt(string, sep) We can also overload it. split(string, sep) // splits in two split(string, sep, count)
Re: replaceFirst, findPieces, and takeExactly
On 1/22/11 5:41 PM, Tomek Sowiński wrote: Andrei Alexandrescu napisał: On 1/22/11 5:14 PM, Nick Sabalausky wrote: Andrei Alexandrescuseewebsiteforem...@erdani.org wrote in message news:ihfm34$jvb$1...@digitalmars.com... On 1/22/11 4:16 PM, bearophile wrote: Andrei: Back then people said that STL's find() is better than D's find() because the former returns an iterator that can be combined with either the first iterator to get the portion before the match, or with the last iterator to get the portion starting at the match. D's find() only gives you the portion after the match. There's a HUGE problem here. This equivalence is sometimes true, but surely not always true: more powerful != better That function allows you to pick a determined number of elements from a range, assuming the range is never shorter than that. That sounds a bit obscure, but plays a pivotal role in findParts() (which is the name I settled on for the equivalent of Python's partition()): trisect is way better than findParts :-) And it's a single word with no uppercase letters in the middle. There is still time until the next release. Votes for trisect? vote-- findParts is the sort of thing that once you read what it does just *once*, it immediately becomes both obvious and easy to remember. But trisect is 1. scary, 2. I'd never remember it, and 3. Whenever I'd come across it, I'd never remember what it meant. Those are paricularly bad since I know right now I'm going to find it an incredibly useful function: There's already been too many times I've written this mess and felt dirty about it: auto result = find(str, delim); auto firstPart = str[0..$-result.length]; So I'm thrilled to see this function being added. Yes, I'm absolutely in agreement with the naming (and thrilled too). I imagine a putative user looking through std.algorithm (let's see... what find functions are out there?). That makes findPieces easy to get to, whereas trisect would be oddly situated in the alphabetic list and oddly named enough to be virtually undiscoverable. Me a tad less, but not because of the name. I'd still rather see a lazy range of pre-hit-post tuples. Am I the only one to see findParts as a no-patterns variation of RegexMatch accepting all element types, not just char? Then even the name comes naturally -- match. Lazy in this case is not very helpful because you don't have the lengths. Turns out it's important to have the length. If not, you can always use until(). Andrei
Re: replaceFirst, findPieces, and takeExactly
On 01/22/2011 11:16 PM, bearophile wrote: That function allows you to pick a determined number of elements from a range, assuming the range is never shorter than that. That sounds a bit obscure, but plays a pivotal role in findParts() (which is the name I settled on for the equivalent of Python's partition()): trisect is way better than findParts :-) And it's a single word with no uppercase letters in the middle. Same for tripartite. Even better because it holds part and is defined as: 1. In three parts. (http://en.wiktionary.org/wiki/tripartite) My 2 cents. (I find findParts uninformative and misleading. Kind of synonym of split.) Denis _ vita es estrany spir.wikidot.com
Re: replaceFirst, findPieces, and takeExactly
On 01/23/2011 12:40 AM, so wrote: Yes, I'm absolutely in agreement with the naming (and thrilled too). I imagine a putative user looking through std.algorithm (let's see... what find functions are out there?). That makes findPieces easy to get to, whereas trisect would be oddly situated in the alphabetic list and oddly named enough to be virtually undiscoverable. If this is the reasoning. This is a split function, not a find. There will be a few more of these split functions i suppose and this is the reason of my proposal splitAt. It is in the definition of the function you quoted. (Split) the string (at) the first occurrence of (sep) splitAt(string, sep) +++ splitAt is simply a Good Name! (even better than tripartite ;-) Also for finding it in list of funcs. Denis _ vita es estrany spir.wikidot.com
Re: replaceFirst, findPieces, and takeExactly
On 01/23/2011 12:40 AM, so wrote: Yes, I'm absolutely in agreement with the naming (and thrilled too). I imagine a putative user looking through std.algorithm (let's see... what find functions are out there?). That makes findPieces easy to get to, whereas trisect would be oddly situated in the alphabetic list and oddly named enough to be virtually undiscoverable. If this is the reasoning. This is a split function, not a find. Agreed, the function does not belong to the sub-list of find*, instead to split*. So's proposal splitAt not only respects that, but tells more accurate information. findPieces does not tell anything, thus anyone would expect it to cut the string into an arbitrary number of pieces. Denis _ vita es estrany spir.wikidot.com
Re: replaceFirst, findPieces, and takeExactly
Am 23.01.2011 04:42, schrieb spir: On 01/23/2011 12:40 AM, so wrote: Yes, I'm absolutely in agreement with the naming (and thrilled too). I imagine a putative user looking through std.algorithm (let's see... what find functions are out there?). That makes findPieces easy to get to, whereas trisect would be oddly situated in the alphabetic list and oddly named enough to be virtually undiscoverable. If this is the reasoning. This is a split function, not a find. There will be a few more of these split functions i suppose and this is the reason of my proposal splitAt. It is in the definition of the function you quoted. (Split) the string (at) the first occurrence of (sep) splitAt(string, sep) +++ splitAt is simply a Good Name! (even better than tripartite ;-) Also for finding it in list of funcs. Denis _ vita es estrany spir.wikidot.com To be honest, tripartite sounds kind of strange. I don't know why, but I think of spiders when I read it ;)
Re: replaceFirst, findPieces, and takeExactly
On 01/22/2011 10:27 PM, Andrei Alexandrescu wrote: The first abstraction is the takeExactly() function: http://d-programming-language.org/cutting-edge/phobos/std_range.html#takeExactly That function allows you to pick a determined number of elements from a range, assuming the range is never shorter than that. That sounds a bit obscure, but plays a pivotal role in findParts() (which is the name I settled on for the equivalent of Python's partition()): What is reasoning behind having length set on takeExactly's result (while if succeeds, you know it, or don't you?), and not on take's result (which can return a smaller number of elements)? I would expect the opposite, or both, but maybe it's only me? Denis _ vita es estrany spir.wikidot.com
Re: replaceFirst, findPieces, and takeExactly
On 01/23/2011 04:49 AM, Daniel Gibson wrote: splitAt is simply a Good Name! (even better than tripartite ;-) Also for finding it in list of funcs. Denis _ vita es estrany spir.wikidot.com To be honest, tripartite sounds kind of strange. I don't know why, but I think of spiders when I read it ;) Don't know why, neither, really poetic association ;-) Denis _ vita es estrany spir.wikidot.com
Re: replaceFirst, findPieces, and takeExactly
On 01/22/2011 10:16 PM, spir wrote: On 01/22/2011 10:27 PM, Andrei Alexandrescu wrote: The first abstraction is the takeExactly() function: http://d-programming-language.org/cutting-edge/phobos/std_range.html#takeExactly That function allows you to pick a determined number of elements from a range, assuming the range is never shorter than that. That sounds a bit obscure, but plays a pivotal role in findParts() (which is the name I settled on for the equivalent of Python's partition()): What is reasoning behind having length set on takeExactly's result (while if succeeds, you know it, or don't you?), and not on take's result (which can return a smaller number of elements)? I would expect the opposite, or both, but maybe it's only me? Denis If the ranges involved are forward ranges, not passing around length information essentially throws away information painstakingly acquired (by means of O(n)). Andrei
Re: replaceFirst, findPieces, and takeExactly
On 01/23/2011 05:30 AM, Andrei Alexandrescu wrote: On 01/22/2011 10:16 PM, spir wrote: On 01/22/2011 10:27 PM, Andrei Alexandrescu wrote: The first abstraction is the takeExactly() function: http://d-programming-language.org/cutting-edge/phobos/std_range.html#takeExactly That function allows you to pick a determined number of elements from a range, assuming the range is never shorter than that. That sounds a bit obscure, but plays a pivotal role in findParts() (which is the name I settled on for the equivalent of Python's partition()): What is reasoning behind having length set on takeExactly's result (while if succeeds, you know it, or don't you?), and not on take's result (which can return a smaller number of elements)? I would expect the opposite, or both, but maybe it's only me? Denis If the ranges involved are forward ranges, not passing around length information essentially throws away information painstakingly acquired (by means of O(n)). Agreed. But why not on take? (Did not check the code, but) the doc says for it: If the range offers random access and length, Take offers them as well. Length information is much more valuable info for take, as it may return less elements than specified. Or what do I miss? Why not (mixed with takeExactly's doc): The result of take(range, n) always defines the length property (and initializea it to actual number of elements) even when range itself does not define length. If the range offers random access, Take offers them as well. ? Denis _ vita es estrany spir.wikidot.com
Re: replaceFirst, findPieces, and takeExactly
On Saturday 22 January 2011 15:19:39 Andrei Alexandrescu wrote: On 1/22/11 5:14 PM, Nick Sabalausky wrote: Andrei Alexandrescuseewebsiteforem...@erdani.org wrote in message news:ihfm34$jvb$1...@digitalmars.com... On 1/22/11 4:16 PM, bearophile wrote: Andrei: Back then people said that STL's find() is better than D's find() because the former returns an iterator that can be combined with either the first iterator to get the portion before the match, or with the last iterator to get the portion starting at the match. D's find() only gives you the portion after the match. There's a HUGE problem here. This equivalence is sometimes true, but surely not always true: more powerful != better That function allows you to pick a determined number of elements from a range, assuming the range is never shorter than that. That sounds a bit obscure, but plays a pivotal role in findParts() (which is the name I settled on for the equivalent of Python's partition()): trisect is way better than findParts :-) And it's a single word with no uppercase letters in the middle. There is still time until the next release. Votes for trisect? vote-- findParts is the sort of thing that once you read what it does just *once*, it immediately becomes both obvious and easy to remember. But trisect is 1. scary, 2. I'd never remember it, and 3. Whenever I'd come across it, I'd never remember what it meant. Those are paricularly bad since I know right now I'm going to find it an incredibly useful function: There's already been too many times I've written this mess and felt dirty about it: auto result = find(str, delim); auto firstPart = str[0..$-result.length]; So I'm thrilled to see this function being added. Yes, I'm absolutely in agreement with the naming (and thrilled too). I imagine a putative user looking through std.algorithm (let's see... what find functions are out there?). That makes findPieces easy to get to, whereas trisect would be oddly situated in the alphabetic list and oddly named enough to be virtually undiscoverable. vote This will be a _fantastic_ function to have. I think that I probably even have an enhancement request somewhere that includes such a function. It's far too common that you have to find something and you want both what is before and after the point that you find. Now, that being the case, I'd probably more commonly find it useful to get the part before what was found and then the part beginning with what was found, but this works too. It is essentially doing what find does, only giving you more stuff in the result, so I do think that it fits well with find, and having its name starting with find means that it will be near find in the documentation, which will make it much easier to find (no pun intended - though I do like puns). The term findParts doesn't really say what the function does (which parts are you looking for, after all?), but it _is_ a name which will be memorable, and once you've read the docs, it will be plenty clear what it does. I certainly can't think of a better name, and I definitely prefer it over the other names that I'm seeing suggested in this thread. - Jonathan M Davis
Re: replaceFirst, findPieces, and takeExactly
On 1/22/11 10:57 PM, spir wrote: On 01/23/2011 05:30 AM, Andrei Alexandrescu wrote: On 01/22/2011 10:16 PM, spir wrote: On 01/22/2011 10:27 PM, Andrei Alexandrescu wrote: The first abstraction is the takeExactly() function: http://d-programming-language.org/cutting-edge/phobos/std_range.html#takeExactly That function allows you to pick a determined number of elements from a range, assuming the range is never shorter than that. That sounds a bit obscure, but plays a pivotal role in findParts() (which is the name I settled on for the equivalent of Python's partition()): What is reasoning behind having length set on takeExactly's result (while if succeeds, you know it, or don't you?), and not on take's result (which can return a smaller number of elements)? I would expect the opposite, or both, but maybe it's only me? Denis If the ranges involved are forward ranges, not passing around length information essentially throws away information painstakingly acquired (by means of O(n)). Agreed. But why not on take? (Did not check the code, but) the doc says for it: If the range offers random access and length, Take offers them as well. Length information is much more valuable info for take, as it may return less elements than specified. Or what do I miss? Why not (mixed with takeExactly's doc): The result of take(range, n) always defines the length property (and initializea it to actual number of elements) even when range itself does not define length. If the range offers random access, Take offers them as well. ? take(r, n) takes at most n elements from r. It is unable to offer length because for an input or forward range that would cost O(n). (For an input range, that would also ruin the range.) takeExactly(r, n) assumes that the range has at least n elements. As such, it is able to offer constant-time length. These are quite different abstractions with different capabilities and power. I have been missing for years a complete solution to findPieces() because I've always wanted to express its results in terms of take() instead of takeExactly(). Only today I figured the puzzle out. Andrei
Re: replaceFirst, findPieces, and takeExactly
On 1/22/11 10:59 PM, Jonathan M Davis wrote: This will be a _fantastic_ function to have. I think that I probably even have an enhancement request somewhere that includes such a function. It's far too common that you have to find something and you want both what is before and after the point that you find. Now, that being the case, I'd probably more commonly find it useful to get the part before what was found and then the part beginning with what was found, but this works too. I suspect there might be a simple and intuitive way to define a family of functions that give you whatever portions of the find you're interested in (before, match, after, before and match, match and after). That could be either a naming convention or a template argument. Any ideas, let me know. Andrei
Re: replaceFirst, findPieces, and takeExactly
Andrei Alexandrescu Wrote: I suspect there might be a simple and intuitive way to define a family of functions that give you whatever portions of the find you're interested in (before, match, after, before and match, match and after). That could be either a naming convention or a template argument. Any ideas, let me know. splitAt splitBefore splitAfter ?
