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
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 reply 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
next sibling parent reply 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
parent reply 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
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 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 next sibling parent reply 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=










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

 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.


=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
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 parent reply 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
 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
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
next sibling 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
parent reply 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
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 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
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
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 reply 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
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