<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>On the Worst-Case Complexity of TimSort · HackerPapers discussions</title><link>https://hackerpaper.kaipfister.de/p/1805.08612/</link><description>Collected HN comments and submissions linking this paper.</description><language>en</language><lastBuildDate>Mon, 02 Nov 2026 11:16:22 GMT</lastBuildDate><atom:link href="https://hackerpaper.kaipfister.de/p/1805.08612/feed.xml" rel="self" type="application/rss+xml" /><item><title>On the Worst-Case Complexity of TimSort — mentioned by elygre</title><link>https://news.ycombinator.com/item?id=17883998</link><guid isPermaLink="false">urn:hackerpapers:mention:1805.08612:17883998</guid><pubDate>Fri, 31 Aug 2018 08:54:15 GMT</pubDate><description>&lt;p&gt;This look like https://bugs.openjdk.java.net/browse/JDK-8203864, which has the following additional information: &amp;quot;While working on a proper complexity analysis of the algorithm, we realised that there was an error in the last paper reporting such a bug (http://envisage-project.eu/wp-content/uploads/2015/02/sortin...). This implies that the correction implemented in the Java source code (changing Timsort stack size) is wrong and that it is still possible to make it break. This is explained in full details in our analysis: https://arxiv.org/pdf/1805.08612.pdf&amp;quot;&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/1805.08612/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.DS</category></item></channel></rss>
