<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 29, 2015, at 7:30 AM, Sergey Bolshedvorsky &lt;<a href="mailto:sergey@bolshedvorsky.com" class="">sergey@bolshedvorsky.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hi Dmitri,</div><div class=""><br class=""></div><div class="">Thank you for your feedback! I’ve updated a proposal based on your comments:&nbsp;<a href="https://github.com/apple/swift-evolution/pull/77" target="_blank" class="">https://github.com/apple/swift-evolution/pull/77</a></div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">What jumps at me immediately is that the APIs are using integers to specify positions in the collection.&nbsp; I think they should be using collection's indices instead.</div></div></div></div></blockquote>Yes you are right, the APIs should use collection indexes.&nbsp;</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">I'm unsure why we need `first` and `last` -- shouldn't the API operate on the whole collection?&nbsp; We have slices to operate on subsequences.</div></div></div></div></blockquote></div><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">The C++ implementation allows to rotate all elements of collection or only some of them. A precondition of this function is that</div><div class="">0 &lt;= first &lt;= middle &lt;= last &lt; count</div></div></div></div></div></div></div></blockquote><div><br class=""></div>This should be handled by slicing and rotating a slice. In-place slice mutation is not yet efficient, but we have an open radar asking for the necessary core language feature to make it so (non-pointer proxy addressors).</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px;" class=""><div dir="ltr" class=""><div class="gmail_extra">Another point to consider is how the call site of these functions looks like:</div></div></blockquote><br class=""></div><div style="margin: 0px; line-height: normal;" class=""><div class="" style="font-size: 11px; font-family: Menlo;">&nbsp;I’ve added 2 API usage examples to PR:</div><div class="" style="font-size: 11px; font-family: Menlo;"><br class=""></div><div class=""><div style="font-size: 11px; font-family: Menlo; margin: 0px; line-height: normal;" class="">Example of rotating all elements of the collection:</div><div style="font-size: 11px; font-family: Menlo; margin: 0px; line-height: normal; min-height: 13px;" class=""><br class=""></div><div style="font-size: 11px; font-family: Menlo; margin: 0px; line-height: normal;" class="">let numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9]</div><div style="font-size: 11px; font-family: Menlo; margin: 0px; line-height: normal;" class="">let rotated = numbers.rotateFrom(0, middle: 3, last: 8)</div><div style="font-size: 11px; font-family: Menlo; margin: 0px; line-height: normal;" class="">// rotated contains&nbsp;[4, 5, 6, 7, 8, 9, 1, 2, 3]</div></div></div></div></div></div></div></div></div></div></blockquote><div><br class=""></div>There should be an in-place rotation algorithm as well, and for both varieties we should have a way of getting back the index of the old start element in the rotated collection. &nbsp;I would start with the in-place algorithms are likely more of a challenge.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><div style="margin: 0px; line-height: normal;" class=""><div class=""><div style="font-size: 11px; font-family: Menlo; margin: 0px; line-height: normal;" class="">Example of rotating some elements of the collection:</div><div style="font-size: 11px; font-family: Menlo; margin: 0px; line-height: normal; min-height: 13px;" class=""><br class=""></div><div style="font-size: 11px; font-family: Menlo; margin: 0px; line-height: normal;" class="">let numbers = [10, 12, 13, 11, 15, 14]</div><div style="font-size: 11px; font-family: Menlo; margin: 0px; line-height: normal;" class="">let rotated = numbers.rotateFrom(1, middle: 3, last: 4)</div><div style="font-size: 11px; font-family: Menlo; margin: 0px; line-height: normal;" class="">// rotated contains [10, 11, 12, 13, 15, 14]</div><div style="font-size: 11px; font-family: Menlo; margin: 0px; line-height: normal;" class=""><br class=""></div><div style="font-size: 11px; font-family: Menlo; margin: 0px; line-height: normal;" class=""><br class=""></div><div style="margin: 0px; line-height: normal;" class=""><blockquote type="cite" style="font-size: 12px; font-family: Helvetica;" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">It is interesting that you are proposing that the new algorithms should produce lazy views.&nbsp; I agree this is consistent with the rest of the library, but I'm worried about the performance implications.&nbsp; Have you thought about this?&nbsp; One point to keep in mind is that you can implement the `_copyToNativeArrayBuffer()` and `_initializeTo()` entry points in all new lazy collections, using the optimal eager algorithm.&nbsp; This way, converting them to arrays will be fast.</div></div></div></div></blockquote><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">Thanks for pointing out the performance issue with lazy views. I will draft the implementation of algorithms for regular collections at first and then I will think how it can be reused with lazy views.</div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></blockquote><div><br class=""></div>Err, I don’t think Dmitri pointed anything out; he merely asked you to consider performance. &nbsp;But I must admit that I don’t understand the concern. &nbsp;Many of our eager algorithms for are implemented by copying lazy views to an array.</div><div><br class=""></div><div>Personally, I would implement a rotate as something like:</div><div><br class=""></div><div>extension CollectionType {</div><div>&nbsp; func rotatedAt(midPoint: Index) -&gt; /* Return type */{</div><div>&nbsp; &nbsp; let result = c.lazy.flatten([ c[midPoint..&lt;c.endIndex], c[startIndex..&lt;midPoint] ])</div><div>&nbsp; &nbsp; // or, for optimization, c.flatten(CollectionOfTwo(c[midPoint..&lt;c.endIndex], c[startIndex..&lt;midPoint] ))&nbsp;</div><div>&nbsp; &nbsp; return (result, calculateIndexOfMidPoint())</div><div>&nbsp; }</div><div>} &nbsp;</div><div><div class=""><br class=""></div><div class="">calculateIndexOfMidPoint can start out being O(N) if necessary; you should be able to add enough API to the LazyFlattenCollection that you can synthesize the position more efficiently though.</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><div style="margin: 0px; line-height: normal;" class=""><div class=""><div style="margin: 0px; line-height: normal;" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">Sergey</div></div></div></div></div></div><div style="font-size: 11px; font-family: Menlo; margin: 0px; line-height: normal;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px;" class=""><div dir="ltr" class=""></div></blockquote></div></div></div></div></div></div></div></div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 29 Dec 2015, at 06:38, Dmitri Gribenko &lt;<a href="mailto:gribozavr@gmail.com" class="">gribozavr@gmail.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Mon, Dec 28, 2015 at 10:29 PM, Sergey Bolshedvorsky via swift-evolution <span dir="ltr" class="">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>&gt;</span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class="">Hi all,<div class=""><br class=""></div><div class="">I have created a PR with with a formal proposal for this feature:&nbsp;<a href="https://github.com/apple/swift-evolution/pull/77" target="_blank" class="">https://github.com/apple/swift-evolution/pull/77</a></div><div class=""><br class=""></div><div class="">What are your thoughts?</div></div></blockquote><div class=""><br class=""></div><div class="">Thank you for the proposal!</div><div class=""><br class=""></div><div class="">What jumps at me immediately is that the APIs are using integers to specify positions in the collection.&nbsp; I think they should be using collection's indices instead.</div><div class=""><br class=""></div><div class="">I'm unsure why we need `first` and `last` -- shouldn't the API operate on the whole collection?&nbsp; We have slices to operate on subsequences.</div><div class=""><br class=""></div><div class="">It is interesting that you are proposing that the new algorithms should produce lazy views.&nbsp; I agree this is consistent with the rest of the library, but I'm worried about the performance implications.&nbsp; Have you thought about this?&nbsp; One point to keep in mind is that you can implement the `_copyToNativeArrayBuffer()` and `_initializeTo()` entry points in all new lazy collections, using the optimal eager algorithm.&nbsp; This way, converting them to arrays will be fast.</div></div><div class="gmail_extra"><br class=""></div>Another point to consider is how the call site of these functions looks like:</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">collection.rotate(10, middle: 20, last: 30)</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">The first number hangs in the air, it is unclear what its meaning is.</div><div class="gmail_extra"><div class=""><br class=""></div><div class="">Dmitri</div><div class=""><br class=""></div>-- <br class=""><div class="gmail_signature">main(i,j){for(i=2;;i++){for(j=2;j&lt;i;j++){if(!(i%j)){j=0;break;}}if<br class="">(j){printf("%d\n",i);}}} /*Dmitri Gribenko &lt;<a href="mailto:gribozavr@gmail.com" target="_blank" class="">gribozavr@gmail.com</a>&gt;*/</div>
</div></div>
</div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></body></html>