<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 <<a href="mailto:sergey@bolshedvorsky.com" class="">sergey@bolshedvorsky.com</a>> 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: <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. 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. </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? 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 <= first <= middle <= last < 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;"> 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 [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. 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. I agree this is consistent with the rest of the library, but I'm worried about the performance implications. Have you thought about this? 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. 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. But I must admit that I don’t understand the concern. 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> func rotatedAt(midPoint: Index) -> /* Return type */{</div><div> let result = c.lazy.flatten([ c[midPoint..<c.endIndex], c[startIndex..<midPoint] ])</div><div> // or, for optimization, c.flatten(CollectionOfTwo(c[midPoint..<c.endIndex], c[startIndex..<midPoint] )) </div><div> return (result, calculateIndexOfMidPoint())</div><div> }</div><div>} </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 <<a href="mailto:gribozavr@gmail.com" class="">gribozavr@gmail.com</a>> 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=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></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: <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. 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? 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. I agree this is consistent with the rest of the library, but I'm worried about the performance implications. Have you thought about this? 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. 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<i;j++){if(!(i%j)){j=0;break;}}if<br class="">(j){printf("%d\n",i);}}} /*Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com" target="_blank" class="">gribozavr@gmail.com</a>>*/</div>
</div></div>
</div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></body></html>