Talk:Splay tree

message: Um. I'm not sure the zigzig step is correct. I implemented it and the performance sucked. Works better if the result from a zigzig zigzags.  —Preceding unsigned comment added by 122.107.243.206 (talk) 02:01, 19 April 2009 (UTC)
replies: text: Yes, I noticed there is a problem with the description of the Zig-zag step and editted it. Please someone check the changes.  — Preceding unsigned comment added by MazinIssa (talk • contribs) 08:06, 11 July 2013 (UTC)
thread_title: Zigzag

message: Someone please do a pseudocode implementation of splay on the main page. (I removed the note suggesting that, since such notes should be confined to the talk pages.) 68.100.96.143
I've been trying to work out a way to balance a splay tree since I saw this article's claim that splay trees are "self-balancing" and support O(log N) "amortized time" insertions and deletions. I have found multiple splay trees that cannot be balanced and also keep the order defined by splaying. I'm changing the "amortized time" for now, but I would like to chat with someone about the idea that a splay tree can self-balance, just in case I'm crazy. Tjdw 14:16, 15 Jan 2004 (UTC)
replies: text: I believe splay trees (at least above a certain size) will be (roughly) balanced (meaning their height will be in O(log n)), or at least cannot stay unbalanced once nodes in unbalanced parts of the tree are accessed. I have not checked for myself, but Sleator and Tarjan state in their original article that the height of nodes on the access path to a node being accessed get approximately halfed. If splay trees could be and stay unbalanced, the given worst-case access time could hardly hold. As many internet sources claim this too, I reintroduced it to the article (otherwise the last paragraph would in my eyes not be correct).DrZ 23:11, 14 May 2004 (UTC)
replies: text: Actually, splay trees are not necessarily self-balancing, they are only stochastically self-balancing. That is why you get O(log n) amortized time - a single access can take n comparisons, just as with a plain binary search tree. It will, however, also somewhat rebalance the tree. Moreover, the insertations that debalance the tree are very cheap, so that in sum you get excellent behaviour. --Stephan Schulz 13:57, 26 May 2005 (UTC)

text: Complexity should be O(log M), unless I misuderstand what you are saying. --Stephan Schulz 13:57, 26 May 2005 (UTC)
replies: text:  I believe you are right. It should be O(log M). Vecter (talk) 16:36, 16 June 2010 (UTC)

text: I agree with you. Randomization for splay trees (as by such authors as Fürer, Albers and Karpinski) only helps to save time on randomly not splaying. And only in some cases. As conjectured, of course, it only improves the working time by a constant factor.  —Preceding unsigned comment added by 129.67.117.122 (talk) 19:38, 7 January 2008 (UTC)
thread_title: tree

message: Can anyone explain to me what "uniform sequence" (of operations) means ? --194.9.67.130 12:48, 26 November 2006 (UTC)
replies: text: Uniform access basically refers to accessing elements of the tree uniformly at random. A uniform sequence of operations to a sequence exhibiting uniform access, i.e., artifacts such as long runs accessing a single node or accessing just a small subset of the nodes are uncommon. It is for non-uniform sequences such as these that splay trees show an advantage. Deco 17:06, 26 November 2006 (UTC)
thread_title:  Uniform sequence

message: Why when you search for splay are you brought here.
A friend was told they had splayed feet I searched for it on here and found nothing but this on the word splay. I have of course found out what it means. But why do you redirect people to this technical description of something else. 
Can you add splay (and it's 2 meanings and multiple uses)? I know I can, but I don't know how to make it stop redirecting
—The preceding unsigned comment was added by 87.74.86.198 (talk • contribs) .
:Just go to this page and edit away. In general, if you come via a redirect, clicking on the little "(Redirected from Splay)" will take you to the page that redirected you. The redirection is part of the page contents, just replace it with whatever you think needs to be said. You probably will create a disambiguation page, so please try to follow the Manual of Style. --Stephan Schulz 22:23, 27 November 2006 (UTC)
thread_title:  Where is Splay? 

message: The sequential access theorem mentions symmetric order. I don't know what that means. The original paper also states the theorem (using the same term), but does not prove it. Does anybody know what this means?  —Preceding unsigned comment added by Raduberinde (talk • contribs) 13:37, 15 September 2007 (UTC)
thread_title:  symmetric order 

message: The last theorem of this section mentions a concrete constant for the upper bound. It is meaningless without knowing which operations are counted. 83.29.230.229 (talk) 19:37, 15 May 2008 (UTC)
thread_title:  Performance theorems 

message: Without being any expert on splay trees it seems like splay trees makes looking up elements into a changing operation which cannot be done from multiple threads at the same time. This is different from most other binary tree and it makes sense to mention it as a performance characteristic.  —Preceding unsigned comment added by 38.99.50.50 (talk) 20:17, 20 April 2010 (UTC)
replies: text: You are absolutely right.  I mentioned this in the disadvantages.  However, I think concurrent find operations can be made to work without much trouble.  First of all, the splay operation need to be in a critical section.  Secondly, we can't splay at a node x if a thread is accessing the parent or grandparent of x.  Thirdly, we don't want two threads performing splay operations to be at nodes too close to each other.  I think everything can be managed in a fairly straightforward way, but the fact that we need to manage it at all is certainly a drawback, and a constant-factor time increase is inevitable. --Jamie King (talk) 16:58, 8 June 2010 (UTC)
replies: text: Modifying during simple get/find operations would lead to cache trashing when cache lines are owned by another CPUs. That would not be a constant time, though. Usually modifying shared state is the worst scalability bottleneck. While releasing the mutex there will be extra write buffers to be flushed as well, the performance would vary depending if the buffers are can settled during cache misses. Bestsss (talk) 00:52, 5 December 2011 (UTC)

text: Top-down splaying can be modified to support concurrency using the method I developed in the paper Concurrent Operations on Priority Queues, CACM 32, 1 (January 1989) -- the algorithm developed there uses skew heaps, but the parallelization method works equally well for top-down splaying.  Each thread completes its operation in an amortized O(log n) time, but a new operation may be started by another thread after O(1) time.  This does indeed create problems with cache thrashing, but it can lead to significant speedups for small scale multithreading. Douglas W. Jones (talk) 14:58, 10 December 2014 (UTC)
thread_title:  Multi threading 

message: It's mentioned that splay trees can be made into a persistent data structure. Intuitively, I don't see how this is true. Certainly you could make insert and delete operations return new trees, but because accesses in a splay tree edit the tree, is everytime you *access* the tree going to return the desired element *and a new tree?* That seems prohibitively expensive, even for a persistent structure.  —Preceding unsigned comment added by 192.160.124.68 (talk) 20:46, 12 May 2010 (UTC)
thread_title:  Persistence 

message: There are too many external links in this article. From WP:EL: "Links in the "External links" section should be kept to a minimum," "Long lists of links are not acceptable." Many of the sites linked to are also of unknown reliability. For example . This seems completely unreliable: . Offliner (talk) 00:46, 8 April 2009 (UTC)
replies: text: I agree.  I removed all but three of the links. --Jamie King (talk) 17:19, 8 June 2010 (UTC)
thread_title:  External links 

message: I've deleted the alleged C code for deletion because a) it was not C and b) it was badly broken.
If we want to give an example implementation, I propose Sleator's original code, released into the public domain :
Tree * delete(int i, Tree * t) {
/* Deletes i from the tree if it's there.			   */
/* Return a pointer to the resulting tree.			   */
	Tree * x;
	if (t==NULL) return NULL;
	t = splay(i,t);
	if (i == t->item) {			   /* found it */
		if (t->left == NULL) {
			x = t->right;
		} else {
			x = splay(i, t->left);
			x->right = t->right;
		}
		size--;
		free(t);
		return x;
	}
	return t;						 /* It wasn't there */
}
or, cleaned up a bit:
/* Deletes i from the tree if it's there.   */
/* Return a pointer to the resulting tree.  */
Tree * delete(int i, Tree * t) 
{
   Tree * x;
   if (t==NULL)
   {
      return NULL;
   } 
   t = splay(i,t);
   if (i == t->item)
   {	 /* found it */
      if (t->left == NULL)
      {
 	 x = t->right;
      }
      else
      {
         x = splay(i, t->left);
	 x->right = t->right;
      }
      size--;
      free(t);
      return x;
   }
   return t;	 /* It wasn't there */
}
Likewise, the original code for splay would be preferable because it needs not "parent" link, unlike the version we present now. --Stephan Schulz (talk) 13:28, 20 April 2011 (UTC)
thread_title:  Deleted deletion 

message: The recursive call to the splay method inserts the same arguments "root" and "x" again. This means that the method need not be done recursively, as it becomes less efficient.
Using recursion in all cases does not really clarify the point of splaying and I was wondering whether it be best that it is turned into a non-recursive method.  —Preceding unsigned comment added by 129.132.45.239 (talk) 15:10, 12 May 2011 (UTC)
replies: text: What do you mean "inserts"? Recursion is a natural approach for tree operations like this. The function calls itself until x==root (after being changed by left and right rotations). I think you'll find an iterative implementation is harder to follow and only marginally more efficient. Maghnus (talk) 00:09, 13 May 2011 (UTC)
thread_title:  Recursion in the implementation of splay method 

message: Watch out since splay function modifies only copy of root. So if you start with some root don't expect it to change when running splay(x, root)!  — Preceding unsigned comment added by 89.67.175.78 (talk) 22:33, 10 January 2013 (UTC)
thread_title:  C code, splay problem 

message: In the find procedure the splay method is not called, thus we are not paying by restructuring the tree for accessing the element. The same reasoning applies to the delete method. If both the left and the right subtrees of the node we want to delete is non-empty then we are taking the minimal element of the right subtree. Again potentially visiting O(n) nodes without calling the splay method.  — Preceding unsigned comment added by 78.131.82.48 (talk) 12:27, 7 June 2017 (UTC)
replies: text: This issue still exists and it is quite an important problem. Lot of my students get confused by this and if anyone actually uses this implementation, it may cause serious problems. I suggest a simple fix - current find method should be made private and possibly renamed and new public find should be made. Public find would just call private find and then do splay (possible dealing with some corner cases)- This way, implementation of all other methods such as insert and delete would remain the same. Mitch.ondra (talk) 15:26, 20 October 2021 (UTC)
thread_title:  The implementation is not correct 

message: Given Splay trees appeared in https://dl.acm.org/doi/10.1145/800061.808752 in 1983 and they are used within Tarjan's Data Structures and Network Algorithms book, shouldn't the year be 1983 instead of 1985? 2A09:80C0:192:0:80F0:4292:4AC1:57E0 (talk) 14:31, 7 February 2024 (UTC)
thread_title:  Year of Invention