timsort (original) (raw)

Martin Buchholz martinrb at google.com
Tue Jul 7 21:56:31 UTC 2009

On Tue, Jul 7, 2009 at 13:28, Christopher Hegarty -Sun Microsystems Ireland <Christopher.Hegarty at sun.com> wrote:

Hi Martin, Josh,

Thank you both for making these changes. Once we have the Blenderev I'll file a CCC request and keep you informed of its status. Martin: I'm signing off for tonight. I can create the Blenderrev tomorrow if you don't get a chance. Also, I think you need an additional 'optional' for the final Arrays.sort method.

Good catch! I did some final fixup of the IAE specs.

It's a cruel world. Although I am the author of BlenderRev, I can't run it myself because it hasn't been open-sourced (and it has a third-party closed-source dependency). Y'all should set up a public BlenderRev server, that would turn a mercurial revision into a BlenderRev. Open-sourcing my Sun ~/bin would be nice.

webrev regenerated.

Martin

-Chris. Martin Buchholz wrote:

Josh, thanks for the implementation notes.

I modified them by - Peters's => Peters' - added a space after a comma - added a

- refilled to fit into 80 cols. I also did a bit of modernization of the javadoc for the 6 related public sort methods. I addressed the issue of insufficient clarity for the optionality of IAE by using "(optional)" + * @throws IllegalArgumentException (optional) if the implementation + * detects that the natural ordering of the list elements is + * found to violate the {@link Comparable} contract

http://cr.openjdk.java.net/~martin/webrevs/openjdk7/timsort/<http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk7/timsort/> Chris, time to generate a blenderrev. You should have one for CCC anyways. I'll include it with my webrev. The ball is in your court. Martin On Tue, Jul 7, 2009 at 12:02, Joshua Bloch <jjb at google.com <mailto:_ _jjb at google.com>> wrote: Chris,

1) Should we update the Arrays class description and appropriate sort methods to now refer to timsort instead of saying: "The sorting algorithm is a modified mergesort...". I know this is not strictly necessary, but you must have considered it already, right? No. I totally missed it. Good catch! I propose this prose: * Implementation note: This implementation is a stable, adaptive, iterative * mergesort that requires far fewer than n lg(n) comparisons when the input * array is partially sorted, while offering the performance of a traditional * mergesort when the input array is randomly ordered. If the input array is * nearly sorted, the implementation requires approximately n comparisons. * Temporary storage requirements vary from a small constant for nearly sorted * input arrays to n/2 object references for randomly ordered input arrays. * *

The implementation takes equal advantage of ascending and

descending order * in its input array, and can take advantage of ascending and descending order * in different parts of the the same input array. It is well-suited to * merging two or more sorted arrays: simply concatenate the arrays and sort * the resulting array. * *

The implementation was adapted from Tim Peters's list sort

 for Python * ( * TimSort). It uses techiques from Peter McIlroy's "Optimistic Sorting * and Information Theoretic Complexity",in Proceedings of the Fourth Annual * ACM-SIAM Symposium on Discrete Algorithms, pp 467-474, January 1993. There are six methods that could use this prose, four in java.uti.Arrays, and two in java.util.Collections. Alternatively, the prose could be included in one place, and linked to repeatedly. Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090707/7e735d9e/attachment.html>

More information about the core-libs-dev mailing list