Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Unfortunately, we programmers are literal beasts.</p> <blockquote> <p>make it a "Balanced" tree.</p> </blockquote> <p>"Balanced" is context dependent. The introductory data structures classes typically refer to a tree being "balanced" when the difference between the node of greatest depth and the node of least depth is minimized. However, as mentioned by Sir Templatetypedef, a splay tree is considered a balancing tree. This is because it can balance trees rather well in cases that few nodes accessed together at one time frequently. This is because it takes less node traversals to get at the data in a splay tree than a conventional binary tree <em>in these cases</em>. On the other hand, its worst-case performance on an access-by-access basis can be as bad as a linked list.</p> <p>Speaking of linked lists...</p> <blockquote> <p>Because otherwise without the "Balancing" it's the same as a linked-list I read and defeats the purpose.</p> </blockquote> <p>It <em>can</em> be as bad, but for randomized inserts it isn't. If you insert already-sorted data, most binary search tree implementations will store data like an bloated and ordered linked list. However, that's only because you're building one side of the tree continually. (Imagine inserting 1, 2, 3, 4, 5, 6, 7, etc... into a binary tree. Try it on paper and see what happens.)</p> <p>If you have to balance in a theoretical worst-case-must-guaranteed sense, I recommend looking up red-black trees. (Google it, second link is pretty good.)</p> <p>If you have to balance it in a reasonable way for this particular scenario, I'd go with integer indices and a decent hash function -- that way the balancing will happen probabilistically without any extra code. That is to say, make your comparison function look like hash(strA) &lt; hash(strB) instead of what you've got now. (For a quick but effective hash for this case, look up FNV hashing. First hit on Google. Go down until you see useful code.) You can worry about the details of implementation efficiency if you want to. (For example, you don't have to perform both hashes every single time you compare since one of the strings never changes.)</p> <p>If you can get away with it, I strongly recommend the latter if you're in a crunch for time and want something fast. Otherwise, red-black trees are worthwhile since they're extremely useful in practice when you need to roll your own height-balanced binary trees.</p> <p>Finally, addressing your code above, see the comments in the code below:</p> <pre><code>int IntBinaryTree::numberNodes(TreeNode *root) { if(root = NULL) // You're using '=' where you want '==' -- common mistake. // Consider getting used to putting the value first -- that is, // "NULL == root". That way if you make that mistake again, the // compiler will error in many cases. return 0; /* if(TreeNode.left=null &amp;&amp; TreeNode.right==null) // Meant to use '==' again. { return 1; } return numberNodes(node.left) + numberNodes(node.right); */ int count = 1; // our actual node if (left != NULL) { // You likely meant 'root.left' on the next line, not 'TreeNode.left'. count += numberNodes(TreeNode.left); // That's probably the line that's giving you the error. } if (right != NULL) { count += numberNodes(root.right); } return count; } </code></pre>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload