But this would lead to boilerplate and inefficiency in cases where slicing isn't needed. Ranges that don't have a better way of dealing with slicing would have to have lowerLim and upperLim variables and add lowerLim every time the range was indexed. While I think the overhead of this is reasonable if the alternative is an algorithm simply not working, I don't think it's reasonable to pay for it (both in execution efficiency and boilerplate code) when it's not going to be used.<br>
<br><div class="gmail_quote">On Fri, Aug 13, 2010 at 2:04 PM, Andrei Alexandrescu <span dir="ltr"><<a href="mailto:andrei@erdani.com">andrei@erdani.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I'd favor simplicity by just requiring random-access ranges to define slicing.<br>
<br>
Andrei<br>
<br>
David Simcha wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
I would agree if we were talking about big-O efficiency, or even a large constant overhead, but IMHO avoiding Slicer is a micro-optimization, not a macro-optimization. Therefore, by default it should "just work" even if it's slightly inefficient and intervention should be required only if the programmer decides it needs to be optimized.<br>
<br></div><div><div></div><div class="h5">
On Fri, Aug 13, 2010 at 1:02 PM, Jonathan M Davis <<a href="mailto:jmdavisprog@gmail.com" target="_blank">jmdavisprog@gmail.com</a> <mailto:<a href="mailto:jmdavisprog@gmail.com" target="_blank">jmdavisprog@gmail.com</a>>> wrote:<br>
<br>
On Thursday, August 12, 2010 20:24:03 David Simcha wrote:<br>
> A whole bunch of stuff in Phobos (including std.range.Radial and<br>
the FFT<br>
> algorithm I just checked in) requires that ranges provided to it have<br>
> slicing. This limitation is a PITA. Should we add a Slicer<br>
meta-range<br>
> that takes a finite random-access range and bolts slicing on in the<br>
> obvious but relatively inefficient way if it's not already<br>
supported and<br>
> simply returns the range if it already supports slicing? This<br>
would be<br>
> used under the hood when slicing is required. For example:<br>
><br>
> struct Slicer(R) if(isRandomAccessRange!R && !hasSlicing!R) {<br>
> R range;<br>
> size_t lowerLim, upperLim;<br>
><br>
> this(R r) {<br>
> this.range = range;<br>
> this.upperLim = range.length;<br>
> }<br>
><br>
> // Range primitives: front, popFront, etc.<br>
><br>
> typeof(this) opSlice(size_t lower, size_t upper) {<br>
> // Error checking<br>
> auto ret = this;<br>
> ret.upperLim -= this.length - upper;<br>
> ret.lowerLim += lower;<br>
> return ret;<br>
> }<br>
> }<br>
><br>
> auto slicer(R)(R range) {<br>
> static if(hasSlicing!R) {<br>
> return range;<br>
> } else {<br>
> return Slicer!(R)(range);<br>
> }<br>
> }<br>
> _______________________________________________<br>
> phobos mailing list<br></div></div>
> <a href="mailto:phobos@puremagic.com" target="_blank">phobos@puremagic.com</a> <mailto:<a href="mailto:phobos@puremagic.com" target="_blank">phobos@puremagic.com</a>><div class="im"><br>
> <a href="http://lists.puremagic.com/mailman/listinfo/phobos" target="_blank">http://lists.puremagic.com/mailman/listinfo/phobos</a><br>
<br>
I'm not sure I like the idea that this would be done without programmer<br>
intervention. If it's inefficient, it'll lead to programmers using<br>
range types<br>
with algorithms that really aren't supposed to take those range<br>
types and<br>
without them realizing the fact that it's inefficient. Having a<br>
means to allow the<br>
programmer to wrap a range to allow it to be used by an algorithm<br>
which it<br>
wouldn't normally work with may be a good idea, but each algorithm<br>
takes certain<br>
types of ranges for a reason, and I'd hate to see much impact to<br>
efficiency<br>
because of internal range wrangling that the programmer using the<br>
function isn't<br>
even aware of.<br>
<br>
- Jonathan M Davis<br>
_______________________________________________<br>
phobos mailing list<br></div>
<a href="mailto:phobos@puremagic.com" target="_blank">phobos@puremagic.com</a> <mailto:<a href="mailto:phobos@puremagic.com" target="_blank">phobos@puremagic.com</a>><div class="im"><br>
<a href="http://lists.puremagic.com/mailman/listinfo/phobos" target="_blank">http://lists.puremagic.com/mailman/listinfo/phobos</a><br>
<br>
<br>
<br></div>
------------------------------------------------------------------------<div class="im"><br>
<br>
_______________________________________________<br>
phobos mailing list<br>
<a href="mailto:phobos@puremagic.com" target="_blank">phobos@puremagic.com</a><br>
<a href="http://lists.puremagic.com/mailman/listinfo/phobos" target="_blank">http://lists.puremagic.com/mailman/listinfo/phobos</a><br>
</div></blockquote><div><div></div><div class="h5">
_______________________________________________<br>
phobos mailing list<br>
<a href="mailto:phobos@puremagic.com" target="_blank">phobos@puremagic.com</a><br>
<a href="http://lists.puremagic.com/mailman/listinfo/phobos" target="_blank">http://lists.puremagic.com/mailman/listinfo/phobos</a><br>
</div></div></blockquote></div><br>