www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - replaceFirst, findPieces, and takeExactly

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
OK, I added replaceFirst:

http://d-programming-language.org/cutting-edge/phobos/std_array.html#replaceFirst

http://www.dsource.org/projects/phobos/changeset/2365

I've also added two crucial abstractions that finally quench my many 
sleepless nights following my Boostcon keynote. 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.

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()):

http://d-programming-language.org/cutting-edge/phobos/std_algorithm.html#findParts

There are many nice things about findParts() that make it feel whole: 
all parts have lengths, their types are the best possible given the 
input, and the amount of information conveyed is maximized.

The implementations of findParts and takeExactly are simple and elegant too:

http://www.dsource.org/projects/phobos/changeset/2365


Andrei
Jan 22 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
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. Bye, bearophile
Jan 22 2011
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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? Andrei
Jan 22 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail 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.
Jan 22 2011
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/22/11 5:14 PM, Nick Sabalausky wrote:
 "Andrei Alexandrescu"<SeeWebsiteForEmail 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
Jan 22 2011
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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 Alexandrescu"<SeeWebsiteForEmail 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
Jan 22 2011
prev sibling next sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
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 ;)
Jan 22 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
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
Jan 22 2011
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 22 2011
parent reply Jim <bitcirkel yahoo.com> writes:
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 ?
Jan 22 2011
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 23 2011
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Jan 23 2011
prev sibling parent spir <denis.spir gmail.com> writes:
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!("a>10")(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
Jan 23 2011
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday 22 January 2011 15:19:39 Andrei Alexandrescu wrote:
 On 1/22/11 5:14 PM, Nick Sabalausky wrote:
 "Andrei Alexandrescu"<SeeWebsiteForEmail 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()):

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
Jan 22 2011
prev sibling next sibling parent so <so so.do> writes:
 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)
Jan 22 2011
prev sibling parent spir <denis.spir gmail.com> writes:
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()):



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
Jan 22 2011
prev sibling next sibling parent Tomek =?ISO-8859-2?Q?Sowi=F1ski?= <just ask.me> writes:
Andrei Alexandrescu napisa=B3:

 On 1/22/11 5:14 PM, Nick Sabalausky wrote:
 "Andrei Alexandrescu"<SeeWebsiteForEmail 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 g=





 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" !=3D "better"
 That function allows you to pick a determined number of elements fro=





 range, assuming the range is never shorter than that. That sounds a =





 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 w=




 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 co=


 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 functi=


 There's already been too many times I've written this mess and felt dir=


 about it:

 auto result =3D find(str, delim);
 auto firstPart =3D 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=20 imagine a putative user looking through std.algorithm ("let's see...=20 what find functions are out there?"). That makes findPieces easy to get=20 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 ran= ge of pre-hit-post tuples. Am I the only one to see findParts as a no-patte= rns variation of RegexMatch accepting all element types, not just char? The= n even the name comes naturally -- match. --=20 Tomek
Jan 22 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
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
Jan 22 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
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
Jan 22 2011
prev sibling parent reply spir <denis.spir gmail.com> writes:
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
Jan 22 2011
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 22 2011
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 22 2011
prev sibling parent spir <denis.spir gmail.com> writes:
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
Jan 22 2011