[Issue 4492] Version of take() which takes from the back of a range

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=4492

Infiltrator  changed:

   What|Removed |Added

 CC||lt.infiltra...@gmail.com

--- Comment #11 from Infiltrator  ---
Andrei, take(retro(arr), n) and arr[$-n..$] seem perfectly reasonable, so do
you want to close this one off?

--

[Issue 4492] Version of take() which takes from the back of a range

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=4492

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |INVALID

--- Comment #12 from Andrei Alexandrescu  ---
(In reply to Infiltrator from comment #11)
> Andrei, take(retro(arr), n) and arr[$-n..$] seem perfectly reasonable, so do
> you want to close this one off?

Yes, thanks.

--

[Issue 4492] Version of take() which takes from the back of a range

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4492


Steven Schveighoffer schvei...@yahoo.com changed:

   What|Removed |Added

 CC||schvei...@yahoo.com


--- Comment #5 from Steven Schveighoffer schvei...@yahoo.com 2010-07-22 
07:50:51 PDT ---
(In reply to comment #2)
 You get the elements in the wrong order. Now, you could do
 
 retro(take(retro(myRange), someNumber))

That won't work, retro needs a bidirectional range, and take is not a
bidirectional range.

Like David said, your takeBack will only work on random access ranges, an O(n)
cost for constructing a range is unacceptable.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4492] Version of take() which takes from the back of a range

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4492



--- Comment #7 from Steven Schveighoffer schvei...@yahoo.com 2010-07-22 
10:46:24 PDT ---
You might misunderstand what I was talking about.

I meant that specific example of a workaround won't work, not that you couldn't
implement takeBack.

As far as I know, the only restriction would be that the input would need to be
a random access range, so you could get the $-Nth element in O(1) time.

I'd probably call it something different however, like takeTail (or just tail),
since back implies you only want the back element, or are starting with the
back element.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4492] Version of take() which takes from the back of a range

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4492



--- Comment #8 from Jonathan M Davis jmdavisp...@gmail.com 2010-07-22 
10:55:26 PDT ---
Ah okay. I did misunderstand what you meant.

takeTail() probably would be a better name.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4492] Version of take() which takes from the back of a range

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4492


David Simcha dsim...@yahoo.com changed:

   What|Removed |Added

 CC||dsim...@yahoo.com


--- Comment #1 from David Simcha dsim...@yahoo.com 2010-07-21 17:31:20 PDT ---
What's wrong with just using take(retro(myRange), someNumber)?  This is only a
tiny bit more typing than takeBack and IIUC does exactly what you want.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4492] Version of take() which takes from the back of a range

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4492



--- Comment #3 from David Simcha dsim...@yahoo.com 2010-07-21 19:16:35 PDT ---
Two points:

1.  Retro is not inefficient.  For random access, there's the overhead of
translating the index to length - index, but this is negligible in most cases
(though I wouldn't use it in super performance critical numerics code).  In the
case of front(), popFront(), etc., all it does is forward front() to back(),
popFront() to popBack() and vice-versa.  These are virtually guaranteed to be
inlined by the compiler, resulting in truly zero overhead for non-random
access.

2.  Sorry for the misunderstanding on what you expected takeBack to do. 
However, now IIUC takeBack would be unimplementable on non-random access
ranges, unless the range had a length **and** you performed an O(n) seek.  If
you can only access the front and back element of a range at any given time,
you can't get the Nth element from the back.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---