I was just wondering,
it it possible to have a binary search tree with no left subtree?
Or does the root must have to children?
Yes, it can. It can also contain 1 item (root only) or even 0 items (empty tree or null tree).
In case of simple BST, try to insert 1, 2, 3, 4, 5, 6, 7 and so on - you will get tree like:
1
\
2
\
3
\
4
\
5
\
6
\
7
...
In this case, searching operation will require O(n) - that's why it is the worst case of binary search tree. Such tree is called unbalanced tree.
In order to avoid such situations we have self-balancing binary search trees.
Related
First:
$ raku -e "for 1...6, 7...15 { .say }"
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Now:
$ raku -e "for 1...3, 7...15 { .say }"
1
2
3
7
11
15
I would expect this case to print 1,2,3,7,8,... 15.
What's happening here?
I think you might want the raku Range operator .. (two dots) and not the raku Sequence operator ... (three dots).
Here's how you examples look with the Range operator instead:
> raku -e 'for 1..6, 7..15 { .say }'
1..6
7..15
Oh, that's not good ... looks like for is just iterating over the two things 1..6 and 7..15 and stringifying them.
We can use a Slip | to fix that:
> raku -e 'for |(1..6), |(7..15) { .say }'
1
2
... (all the numbers)
14
15
And then:
raku -e 'for |(1..3), |(7..15) { .say }'
1
2
3
7
8
9
10
11
12
13
14
15
With the Sequence operator, you have made something like:
>raku -e 'for 3,7...15 { .say }'
3
7
11
15
That is raku for "make a sequence that starts with 3, then 7, then all the values until you get to the last at 15" ... and since the gap from 3 to 7 is 4, raku will count up in steps of 4. Then you began it with 1..3. ;-)
~p6steve
It's because it is two deductive sequences.
1...3
Is obviously a sequence where you add 1 to each successive value.
1, 2, 3
And since 7 is 4 more than 3, this is a sequence where you add 4 to each successive value.
3, 7 ... 15
3, 7, 11, 15
To get what you want, you could use a flattened Range.
1...3, |(7..15)
Or even a flattened Sequence.
1...3, |(7...15)
TL;DR This answer focuses on addressing what you originally asked (which was about "sequences") and precisely what the code you wrote is doing, rather than providing a solution (using ranges instead).
This is a work in progress dealing with something that seems both poorly documented and hard to fathom (which may explain part though not all of the doc situation). Please bear with me! (And I may just end up deleting this answer.)
1 ... 3, 7 ... 15 ≡ 1 ... (3, 7) ... 15
In the absence of parentheses, operators within an expression are applied according to rules of "precedence" and "associativity".
Infix , has a higher precedence than infix ....¹ The above two lines of code thus produce the same result (12371115):
for 1 ... 3, 7 ... 15 { .say } # Operator evaluation by precedence
for 1 ... (3, 7) ... 15 { .say } # Operator evaluation by parentheses
That said, while the result is what, given a glance at the code, I would expect based on my own "magical" DWIM ("Do What I Mean") thinking, I must say I don't yet know what the precise Raku(do)'s rule(s) are that lead to it DWIMing.
The doc for infix ... says:
If the endpoint is not *, it's smartmatched against each generated element and the sequence is terminated when the smartmatch succeeded.
But that seems overly simple. What if the endpoint of one sequence is another sequence? (As, at least taking a naive view, appears to be the case in your code.)
Also, as #MustafaAydin has noted:
how does your post explain the irregular last step size (of 2) instead of 3? I mean 4, 7 ... 15 alone produces (4, 7, 10, 13). But 1... 4, 7...15 now produces 7, 10, 13, 15 in the tail. Why is 15 included? Maybe i'm missing something idk
I'm at least as confused as Mustafa.
Indeed, I'm confused about several things. How come Raku(do) flattens the two sequences? [D'oh. Because the infix comma is higher precedence than the infix ....] Why doesn't it repeat the 3 in the final combined list? [Perhaps because multiple infix ...s are smart about what to do when there's an expression that's the endpoint of one sequence and the start of another?]
I'm going to go read the old design docs and/or spelunk roast and/or the Rakudo compiler code to see if I can see what's supposedly/actually going on. But not tonight.
Footnotes
¹ There's a table of operators in the current official operator doc. Supposedly this table:
summarizes the precedence levels offered by Raku, listing them in order from high to low precedence.
Unfortunately, at the time of writing this, the central operator table in the Operators page is profoundly wrong #4071.
Until that's fixed, here are "official" and "unofficial" options for determining the precedence of operators:
"official" Use in page search to search the official doc operator page for the operator of interest. Skip to the match in the entries on the left hand side of that same page. As you'll see, infix ,' is one level higher precedence than infix ...`:
Comma operator precedence
infix ,
infix :
List infix precedence
infix Z
infix X
infix ...
"unofficial" Look at the corresponding page of a staging site for an improved doc site. (I don't know how up to date it is, but the central table appears to list operators by precedence order as it claims.)
I encountered the following question:
The Height of a BST constructed from the following list of values 10 , 5 , 4 , 3 , 2 , 1 , 0 , 9 , 13 , 11 , 12 , 16 , 20 , 30 , 40 , 14 will be:
A) 5
B) 6
C) 7
D) 8
Now to certain point I can construct the Tree with no problem because there aren't many choices to insert the values so from the first value 10 to the eleventh value 12 my tree would go like this:
10
/ \
5 13
/ \ /
4 9 11
/ \
3 12
/
2
/
1
/
0
But after that, now I have to add the value 16 and I have two choices to make it the right child of the value 12 or to make it the right child of the value 13 and the height would differ according to this choice, so what's the right approach here?
A binary search tree is a binary tree (that is, every node has at most 2 children) where for each node in the tree, all nodes in the left subtree rooted at that node are less than the root of the subtree and all nodes in the right subtree rooted at that node are greater than the root of the subtree.
Your walkthrough so far assumes a "naive" insertion algorithm that makes no attempt at balancing the tree and inserts the nodes in sequence by recursively comparing against each node from the root. Under typical circumstances, you would not want to build such an unbalanced tree because the performance of operations devolves into O(n) time instead of the optimal O(log(n)) time, which defeats the purpose of the BST structure.
Making 16 the right child of 12 would be an invalid choice because 16 as a left child of 13 violates the BST property. By definition, every insertion must go in one location, so there are no choices to be made, at least following this naive algorithm.
Following through with your approach, it should be clear that the final height (longest root-to-leaf path) will be 7 in any case due to the unbalanced left branch.
However, if the question is to find the height of an optimal tree, then the correct answer is 5. The below illustrates a complete tree (that is, every level is full except the bottom level, and that level has all elements to the left) that can be built from the given data:
11
+---------------+
4 16
+------+ +-------+
2 9 14 30
+---+ +---+ +---+ +---+
1 3 5 10 12 13 20 40
+--
0
Take a look at self-balancing binary search tree data structures for more information on algorithms that can build such a tree.
I have read this: https://www.topcoder.com/community/competitive-programming/tutorials/binary-search.
I can't understand some parts==>
What we can call the main theorem states that binary search can be
used if and only if for all x in S, p(x) implies p(y) for all y > x.
This property is what we use when we discard the second half of the
search space. It is equivalent to saying that ¬p(x) implies ¬p(y) for
all y < x (the symbol ¬ denotes the logical not operator), which is
what we use when we discard the first half of the search space.
But I think this condition does not hold when we want to find an element(checking for equality only) in an array and this condition only holds when we're trying to find Inequality for example when we're searching for an element greater or equal to our target value.
Example: We are finding 5 in this array.
indexes=0 1 2 3 4 5 6 7 8
1 3 4 4 5 6 7 8 9
we define p(x)=>
if(a[x]==5) return true else return false
step one=>middle index = 8+1/2 = 9/2 = 4 ==> a[4]=5
and p(x) is correct for this and from the main theory, the result is that
p(x+1) ........ p(n) is true but its not.
So what is the problem?
We CAN use that theorem when looking for an exact value, because we
only use it when discarding one half. If we are looking for say 5,
and we find say 6 in the middle, the we can discard the upper half,
because we now know (due to the theorem) that all items in there are > 5
Also notice, that if we have a sorted sequence, and want to find any element
that satisfies an inequality, looking at the end elements is enough.
I have a string of ones and zeros, zero mean left and ones mean right, and I need to return the item to the end of the path. If the path leads to nothing returns null.
Tree:
15
/ \
12 18
/ / \
10 16 20
\ \
11 17
String 001 will return 11
String 101 will return 17
String 1111 will return null
How can I write this method in Java?
you can traverse among this tree and check for each character of the string if it is 0 then getleft() and if it is 1 then getright()
and so on, i hope this help :D
i have a midterm tomorrow so i don't have time to write it's implementation now :D
Lets say we are dealing with the keys 1-15. To get the worst case performance of a regular BST, you would insert the keys in ascending or descending order as follows:
1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
Then the BST would essentially become a linked list.
For best case of a BST you would insert the keys in the following order, they are arranged in such a way that the next key inserted is half of the total range to be inserted, so the first is 15/2 = 8, then 8/2 = 4 etc...
8, 4, 12, 2, 6, 10, 14, 1, 3, 5, 7, 9, 11, 13, 15
Then the BST would be a well balanced tree with optimal height 3.
The best case for a red black tree can also be constructed with the best case from a BST. But how do we construct the worst case for a red black tree? Is it the same as the worst case for a BST? Is there a specific pattern that will yield the worst case?
You are looking for a skinny tree, right? This can be produced by inserting [1 ... , 2^(n+1)-2] in reverse order.
You won't be able to. A Red-Black Tree keeps itself "bushy", so it would rotate to fix the imbalance. The length of your above worst case for a Red-Black Tree is limited to two elements, but that's still not a "bad" case; it's what's expected, as lg(2) = 1, and you have 1 layer past the root with two elements. As soon as you add the third element, you get this:
B B
\ / \
R => R R
\
R