## digitalmars.D - replaceFirst, findPieces, and takeExactly

• Andrei Alexandrescu (23/23) Jan 22 2011 OK, I added replaceFirst:
• bearophile (6/16) Jan 22 2011 There's a HUGE problem here. This equivalence is sometimes true, but sur...
• Andrei Alexandrescu (3/17) Jan 22 2011 There is still time until the next release. Votes for trisect?
• Nick Sabalausky (13/36) Jan 22 2011 vote--
• Andrei Alexandrescu (7/45) Jan 22 2011 Yes, I'm absolutely in agreement with the naming (and thrilled too). I
• so (9/14) Jan 22 2011 If this is the reasoning. This is a split function, not a find.
• spir (8/19) Jan 22 2011 +++
• Daniel Gibson (3/25) Jan 22 2011 To be honest, tripartite sounds kind of strange.
• spir (6/16) Jan 22 2011 Don't know why, neither, really poetic association ;-)
• spir (9/15) Jan 22 2011 Agreed, the function does not belong to the sub-list of find*, instead
• Tomek =?ISO-8859-2?Q?Sowi=F1ski?= (15/64) Jan 22 2011 m a
• Andrei Alexandrescu (5/56) Jan 22 2011 Lazy in this case is not very helpful because you don't have the
• Jonathan M Davis (18/66) Jan 22 2011 ++++++++++++++++++++++++++++++++vote
• Andrei Alexandrescu (7/13) Jan 22 2011 I suspect there might be a simple and intuitive way to define a family
• Jim (5/10) Jan 22 2011 splitAt
• Andrei Alexandrescu (7/17) Jan 23 2011 That's a good suggestion, thanks. One issue is that if the element type
• spir (17/31) Jan 23 2011 Guess (tell me if I'm wrong) english says "cut into pieces". Thus, I wou...
• spir (11/16) Jan 22 2011 Same for "tripartite". Even better because it holds "part" and is
• spir (9/15) Jan 22 2011 What is reasoning behind having length set on takeExactly's result
• Andrei Alexandrescu (5/21) Jan 22 2011 If the ranges involved are forward ranges, not passing around length
• spir (13/36) Jan 22 2011 Agreed. But why not on take? (Did not check the code, but) the doc says ...
• Andrei Alexandrescu (11/49) Jan 22 2011 take(r, n) takes at most n elements from r. It is unable to offer length...
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
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
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
"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

auto result = find(str, delim);
auto firstPart = str[0..\$-result.length];

So I'm thrilled to see this function being added.
```
Jan 22 2011
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

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

split(string, sep) // splits in two
split(string, sep, count)
```
Jan 22 2011
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
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
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
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
```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=

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

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

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

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

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

ty

auto result =3D find(str, delim);
auto firstPart =3D str[0..\$-result.length];

So I'm thrilled to see this function being added.

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

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

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

"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

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

- Jonathan M Davis
```
Jan 22 2011
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
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
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
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
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!
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
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()):

"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
```
Jan 22 2011
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
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
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
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