1
00:00:00,090 --> 00:00:02,490
The following content is
provided under a Creative

2
00:00:02,490 --> 00:00:04,059
Commons license.

3
00:00:04,059 --> 00:00:06,360
Your support will help
MIT OpenCourseWare

4
00:00:06,360 --> 00:00:10,720
continue to offer high quality
educational resources for free.

5
00:00:10,720 --> 00:00:13,320
To make a donation or
view additional materials

6
00:00:13,320 --> 00:00:17,280
from hundreds of MIT courses,
visit MIT OpenCourseWare

7
00:00:17,280 --> 00:00:21,110
at ocw.mit.edu

8
00:00:21,110 --> 00:00:24,240
PROFESSOR: All right today we
begin a topic dear to my heart.

9
00:00:24,240 --> 00:00:26,430
It's a problem that's
still pretty open,

10
00:00:26,430 --> 00:00:27,840
but I've worked on a lot.

11
00:00:27,840 --> 00:00:29,400
Dynamic optimality.

12
00:00:29,400 --> 00:00:32,850
Central question here is, is
there one binary search tree

13
00:00:32,850 --> 00:00:35,310
that's at least as good as
all other binary search trees?

14
00:00:35,310 --> 00:00:38,580
Is there one binary search
tree to rule them all?

15
00:00:38,580 --> 00:00:40,230
It's kind of a
fundamental question.

16
00:00:40,230 --> 00:00:42,980
Goes back to the '80s.

17
00:00:42,980 --> 00:00:46,580
In particular splay trees, which
you have probably seen before.

18
00:00:46,580 --> 00:00:49,080
We'll review them briefly here.

19
00:00:49,080 --> 00:00:50,820
And there's a lot of
technology built up,

20
00:00:50,820 --> 00:00:53,670
which we'll talk about this
lecture and next lecture,

21
00:00:53,670 --> 00:00:56,050
about how to tackle
this problem.

22
00:00:56,050 --> 00:00:59,310
It's still active
area of research.

23
00:00:59,310 --> 00:01:06,580
So before I get to-- well
the central question here is,

24
00:01:06,580 --> 00:01:13,500
is there one best
binary search tree?

25
00:01:16,634 --> 00:01:19,050
It's a natural question because
we use binary search trees

26
00:01:19,050 --> 00:01:19,591
all the time.

27
00:01:19,591 --> 00:01:21,510
Already in this class,
probably every lecture,

28
00:01:21,510 --> 00:01:24,190
we've used a binary
search tree for something.

29
00:01:24,190 --> 00:01:30,880
And we all know how to do order
log in balanced binary search

30
00:01:30,880 --> 00:01:31,380
trees.

31
00:01:35,760 --> 00:01:38,940
And the question becomes,
is this the best you can do?

32
00:01:49,590 --> 00:01:59,260
To make this more formal
of a problem, well, yeah.

33
00:01:59,260 --> 00:02:05,340
I want to define binary search
tree as a model of computation.

34
00:02:05,340 --> 00:02:07,640
OK we've talked about
pointer machine model.

35
00:02:07,640 --> 00:02:10,930
Binary search tree model is
a more restricted version

36
00:02:10,930 --> 00:02:11,980
of pointer machine.

37
00:02:11,980 --> 00:02:14,920
So it's less than
pointer machine.

38
00:02:18,270 --> 00:02:21,940
Just so it's clear what
the name of this game is,

39
00:02:21,940 --> 00:02:30,820
we require the data to be
stored in a binary search

40
00:02:30,820 --> 00:02:34,525
tree as it's keys.

41
00:02:40,120 --> 00:02:42,550
And then we allow
basic operations.

42
00:02:46,610 --> 00:02:51,910
Let me make sure I
get the right list.

43
00:03:01,950 --> 00:03:03,930
You can follow
pointers, and we're

44
00:03:03,930 --> 00:03:07,140
going to assume our BST
has left triad pointers,

45
00:03:07,140 --> 00:03:09,270
right triad pointers,
and parent pointers.

46
00:03:09,270 --> 00:03:11,370
You can do each of
these in constant time.

47
00:03:11,370 --> 00:03:14,850
And then the interesting one,
interesting thing you can do,

48
00:03:14,850 --> 00:03:18,210
is rotate a node and its parent.

49
00:03:23,550 --> 00:03:26,960
So sure you've seen
rotations before.

50
00:03:34,160 --> 00:03:36,410
If this is my node
x, and I do rotate

51
00:03:36,410 --> 00:03:43,070
x, it's going to be my
definition of rotation,

52
00:03:43,070 --> 00:03:44,840
x moves to the root.

53
00:03:44,840 --> 00:03:47,770
It's in this case because x
is to the right of it's parent

54
00:03:47,770 --> 00:03:51,870
it remains now to the
right of it's, what

55
00:03:51,870 --> 00:03:52,940
now becomes it's child.

56
00:03:56,100 --> 00:03:58,250
These sub-trees come
along for the ride.

57
00:03:58,250 --> 00:04:01,280
This preserves the binary
search tree property.

58
00:04:01,280 --> 00:04:03,564
And you could get
back by rotating y.

59
00:04:06,230 --> 00:04:08,547
OK by this definition
of rotate we

60
00:04:08,547 --> 00:04:10,130
don't need to
distinguish between left

61
00:04:10,130 --> 00:04:12,230
and right rotations.

62
00:04:12,230 --> 00:04:15,490
We always name the child and
it's parent is well defined.

63
00:04:15,490 --> 00:04:17,190
That's who we rotate with.

64
00:04:17,190 --> 00:04:20,010
So it's just flipping this edge.

65
00:04:20,010 --> 00:04:23,120
So these are the operations
you can do, and in this model

66
00:04:23,120 --> 00:04:25,190
really the only thing
you can do is a search.

67
00:04:25,190 --> 00:04:27,650
Suppose I want to
search for a key.

68
00:04:27,650 --> 00:04:38,300
The model is to do a search I
start at the root of the tree,

69
00:04:38,300 --> 00:04:39,620
of the binary search tree.

70
00:04:39,620 --> 00:04:40,670
I can do these walks.

71
00:04:40,670 --> 00:04:42,500
I could do rotations.

72
00:04:42,500 --> 00:04:44,930
And I must visit--

73
00:04:44,930 --> 00:04:55,970
if I'm going to search for x,
must visit the node with key

74
00:04:55,970 --> 00:04:58,160
equal to x.

75
00:04:58,160 --> 00:05:00,290
And we're going to assume
throughout these lectures

76
00:05:00,290 --> 00:05:01,850
that searches are
always successful.

77
00:05:01,850 --> 00:05:04,557
You're only searching for
keys that are in the tree.

78
00:05:04,557 --> 00:05:06,140
Doesn't make that
much of a difference

79
00:05:06,140 --> 00:05:08,000
if you're searching for keys
that are not in the tree.

80
00:05:08,000 --> 00:05:10,880
Think of it as searching for the
predecessor or the successor.

81
00:05:10,880 --> 00:05:12,146
Not a big deal.

82
00:05:12,146 --> 00:05:13,520
And so for
simplicity, we're just

83
00:05:13,520 --> 00:05:16,820
going to assume
successful searches.

84
00:05:16,820 --> 00:05:19,790
We're also going to assume
no insertions and deletions

85
00:05:19,790 --> 00:05:24,020
in this model, because they just
make problem a little messier.

86
00:05:24,020 --> 00:05:26,690
Some papers have considered
insertions and deletions,

87
00:05:26,690 --> 00:05:28,670
and to the large extent
things just work.

88
00:05:28,670 --> 00:05:31,150
So, we're going to
focus on searches.

89
00:05:31,150 --> 00:05:34,740
Searches is interesting
enough for this problem.

90
00:05:34,740 --> 00:05:36,380
Suppose I have n items.

91
00:05:36,380 --> 00:05:37,730
Now the model is clear.

92
00:05:37,730 --> 00:05:40,067
I store them in a
binary search tree.

93
00:05:40,067 --> 00:05:41,900
These are the only
things I'm allowed to do.

94
00:05:46,520 --> 00:05:50,630
Could I imagine beating log n?

95
00:05:50,630 --> 00:05:54,860
Well, no in the worst case.

96
00:05:54,860 --> 00:05:56,630
This is best possible
in the worst case.

97
00:06:02,930 --> 00:06:04,310
Why?

98
00:06:04,310 --> 00:06:06,850
Because your tree has
to have depth at least

99
00:06:06,850 --> 00:06:10,550
log n if you're going to store
n things, and if it's binary.

100
00:06:10,550 --> 00:06:12,895
So your adversary could
always be, could always just

101
00:06:12,895 --> 00:06:14,270
look at your tree
and say, Oh I'm

102
00:06:14,270 --> 00:06:18,214
going to pick anybody who's
a log in depth or lower,

103
00:06:18,214 --> 00:06:19,880
and if you're going
to start at the root

104
00:06:19,880 --> 00:06:21,447
and walk left and
right to get there,

105
00:06:21,447 --> 00:06:23,030
you're going to have
to pay log n time

106
00:06:23,030 --> 00:06:27,010
every single, every
single operation.

107
00:06:27,010 --> 00:06:29,010
So actually there's a lot
of sequences, in fact,

108
00:06:29,010 --> 00:06:29,635
most sequences.

109
00:06:29,635 --> 00:06:32,870
You take an average sequence,
this will be the case.

110
00:06:32,870 --> 00:06:36,840
But we'll see formal ways
to prove that next class.

111
00:06:36,840 --> 00:06:38,720
But, easy adversary
argument tells you

112
00:06:38,720 --> 00:06:42,210
you need to go down,
log n in the worst case.

113
00:06:44,900 --> 00:06:48,180
But, that's the worst case.

114
00:06:48,180 --> 00:06:50,150
The name of the game
in dynamic optimality

115
00:06:50,150 --> 00:06:53,660
is to consider every case
separately, and do as

116
00:06:53,660 --> 00:06:55,070
well as you can all the time.

117
00:06:55,070 --> 00:06:58,190
In general, the answer
to this question is that,

118
00:06:58,190 --> 00:07:00,350
is log n best possible?

119
00:07:00,350 --> 00:07:03,519
Depends on the access sequence.

120
00:07:03,519 --> 00:07:05,060
Depends on what
you're searching for.

121
00:07:15,750 --> 00:07:23,310
So, let's say we're, to
make things a little clean,

122
00:07:23,310 --> 00:07:26,640
let's assume that the
key is we're storing are

123
00:07:26,640 --> 00:07:30,132
the numbers,
integers, one up to n.

124
00:07:30,132 --> 00:07:31,590
So in particular
there's n of them.

125
00:07:31,590 --> 00:07:33,630
And really we just
care about their order,

126
00:07:33,630 --> 00:07:37,080
so I'm going to relabel
them to be one up to n.

127
00:07:37,080 --> 00:07:46,620
And say we search for x 1
first, then we search for x 2,

128
00:07:46,620 --> 00:07:51,060
and so on, up to x m.

129
00:07:51,060 --> 00:07:54,300
So, these indices
are time, basically.

130
00:07:54,300 --> 00:07:57,350
Over time, and you can
plot this if you like.

131
00:07:57,350 --> 00:07:59,900
Here is time.

132
00:07:59,900 --> 00:08:02,440
Here is space.

133
00:08:02,440 --> 00:08:07,830
So at the first time
unit we search at x 1,

134
00:08:07,830 --> 00:08:11,100
then some other place,
then some other place.

135
00:08:11,100 --> 00:08:15,590
We can have repeats, whatever.

136
00:08:15,590 --> 00:08:16,380
OK.

137
00:08:16,380 --> 00:08:19,440
Some search sequences
are going to be slow,

138
00:08:19,440 --> 00:08:21,630
they're going to require
log n time per access.

139
00:08:21,630 --> 00:08:23,970
In particular, if I always,
if the adversary chooses

140
00:08:23,970 --> 00:08:27,180
x i to be the deepest node
in the tree repeatedly.

141
00:08:27,180 --> 00:08:29,475
But some search sequences
are going to be fast.

142
00:08:33,240 --> 00:08:37,049
Any suggestions, if you don't
have the notes in front of you,

143
00:08:37,049 --> 00:08:42,344
of access sequences that we
can do in less than log n

144
00:08:42,344 --> 00:08:43,135
time per operation.

145
00:08:43,135 --> 00:08:46,150
Let's A constant.

146
00:08:46,150 --> 00:08:48,410
There's a lot of possible
answers, I think.

147
00:08:54,710 --> 00:08:55,210
Yeah?

148
00:08:55,210 --> 00:08:57,170
AUDIENCE: N divided by two.

149
00:08:57,170 --> 00:08:59,180
PROFESSOR: N divided by two.

150
00:08:59,180 --> 00:09:01,070
What do you mean.

151
00:09:01,070 --> 00:09:04,939
AUDIENCE: Like it's
going to be [INAUDIBLE]

152
00:09:04,939 --> 00:09:06,980
PROFESSOR: Oh, if you're
searching for the median

153
00:09:06,980 --> 00:09:08,680
in a perfectly balanced tree?

154
00:09:08,680 --> 00:09:10,959
Yeah, that's true.

155
00:09:10,959 --> 00:09:13,250
So if you're always searching
for the root of the tree,

156
00:09:13,250 --> 00:09:17,120
in particular, that's
going to be good.

157
00:09:17,120 --> 00:09:19,430
That's hard to, that
depends on the tree though.

158
00:09:19,430 --> 00:09:21,710
I'd like a particular
access sequence

159
00:09:21,710 --> 00:09:27,450
that I can always serve
as well, with some tree.

160
00:09:27,450 --> 00:09:28,830
AUDIENCE: n order walk.

161
00:09:28,830 --> 00:09:29,840
PROFESSOR: n order walk.

162
00:09:29,840 --> 00:09:31,620
Yeah, good.

163
00:09:31,620 --> 00:09:37,440
So this has a name.

164
00:09:37,440 --> 00:09:38,850
Sequential access property.

165
00:09:46,870 --> 00:09:51,200
If you want to access the
elements in order, so one

166
00:09:51,200 --> 00:09:56,520
through n, this should only
cost constant amortized.

167
00:10:02,737 --> 00:10:04,570
Because for any tree
you can do and in order

168
00:10:04,570 --> 00:10:06,220
walk in linear time.

169
00:10:06,220 --> 00:10:10,690
And so per search, if you're
careful about how you do this,

170
00:10:10,690 --> 00:10:14,860
now this is not totally obvious
in the model that I've set up,

171
00:10:14,860 --> 00:10:17,690
because I said search
always starts at the root.

172
00:10:17,690 --> 00:10:20,260
If you let your search
start where you left off,

173
00:10:20,260 --> 00:10:22,570
then you can definitely do this.

174
00:10:22,570 --> 00:10:24,760
It turns out you can
assume this or not,

175
00:10:24,760 --> 00:10:26,350
it doesn't make a difference.

176
00:10:26,350 --> 00:10:27,607
That's maybe a fun exercise.

177
00:10:27,607 --> 00:10:29,440
But if, you can essentially
reroute the tree

178
00:10:29,440 --> 00:10:31,842
to be wherever you left off.

179
00:10:31,842 --> 00:10:34,250
I'm not going to
prove that here.

180
00:10:34,250 --> 00:10:38,920
OK, but in particular, some
trees have this property.

181
00:10:38,920 --> 00:10:39,610
Some don't.

182
00:10:39,610 --> 00:10:42,068
I mean if you use a red black
tree, and you search for one,

183
00:10:42,068 --> 00:10:43,780
then search for two,
then search for n,

184
00:10:43,780 --> 00:10:45,610
you're not going to
get constant amortized,

185
00:10:45,610 --> 00:10:47,750
because it doesn't
realize this is happening.

186
00:10:47,750 --> 00:10:51,616
But if you're clever, of
course, this can be achieved.

187
00:10:51,616 --> 00:10:52,990
Easy way to see
how to achieve it

188
00:10:52,990 --> 00:10:57,500
is, this is your
binary search tree.

189
00:10:57,500 --> 00:11:00,160
You access one, then
you do a rotation

190
00:11:00,160 --> 00:11:01,920
with the right child of one.

191
00:11:01,920 --> 00:11:05,350
So then you have this
binary search tree,

192
00:11:05,350 --> 00:11:09,970
and then you access two,
and then you do a rotation.

193
00:11:09,970 --> 00:11:14,710
This is basically a
way to make a deck.

194
00:11:14,710 --> 00:11:18,880
View a, use a link, simulate a
linked list in a binary search

195
00:11:18,880 --> 00:11:20,260
tree.

196
00:11:20,260 --> 00:11:24,860
OK, so it definitely can be
done by some binary search tree.

197
00:11:24,860 --> 00:11:28,305
A stronger version of the
sequential access property,

198
00:11:28,305 --> 00:11:32,800
it's a little more interesting,
is dynamic finger property.

199
00:11:32,800 --> 00:11:35,740
This is something that should
hold for every access sequence,

200
00:11:35,740 --> 00:11:38,200
and it gives you a measure
of how expensive an access

201
00:11:38,200 --> 00:11:39,820
sequence is.

202
00:11:39,820 --> 00:11:43,240
So we're doing x
one x two up to x m.

203
00:11:43,240 --> 00:11:50,350
And we say, if we
measure the key distance

204
00:11:50,350 --> 00:11:53,770
between our current access,
x i and the previous access,

205
00:11:53,770 --> 00:11:55,290
x i minus 1.

206
00:11:55,290 --> 00:11:59,500
If that equals k,
then ideally we

207
00:11:59,500 --> 00:12:03,670
should be able to do log
k amortize per operation.

208
00:12:06,184 --> 00:12:07,600
So in the worst
case this is going

209
00:12:07,600 --> 00:12:12,940
to be log n, but if I look
at my space-time diagram

210
00:12:12,940 --> 00:12:17,950
here, if for example, if
I do sequential access,

211
00:12:17,950 --> 00:12:21,850
then this number is always one,
and so I get constant time.

212
00:12:21,850 --> 00:12:26,920
If I do something like this,
where my spatial distance is

213
00:12:26,920 --> 00:12:28,930
not changing too much,
and this is the reason

214
00:12:28,930 --> 00:12:31,060
I numbered the keys like this.

215
00:12:31,060 --> 00:12:33,700
What I really mean is, in
the sorted order of the keys,

216
00:12:33,700 --> 00:12:35,410
how do the ranks differ.

217
00:12:35,410 --> 00:12:37,720
But if I number the
keys one through n,

218
00:12:37,720 --> 00:12:40,589
that's just their
absolute difference.

219
00:12:40,589 --> 00:12:42,130
So anything like
this, dynamic finger

220
00:12:42,130 --> 00:12:45,874
properly tells you
you're doing well.

221
00:12:45,874 --> 00:12:48,290
Dynamic finger property can
be achieved by a binary search

222
00:12:48,290 --> 00:12:51,540
tree, but it's quite difficult
as you might imagine.

223
00:12:51,540 --> 00:12:56,400
Or it's difficult, let's say
not necessarily super hard.

224
00:12:56,400 --> 00:12:58,980
If you don't need to do it in
a binary search tree model,

225
00:12:58,980 --> 00:13:01,290
an easy way to do
it is with what's

226
00:13:01,290 --> 00:13:02,490
called a level linked tree.

227
00:13:04,849 --> 00:13:06,390
So a level link tree
looks like this,

228
00:13:06,390 --> 00:13:08,940
and I add pointers
between adjacent nodes

229
00:13:08,940 --> 00:13:10,282
in the same level.

230
00:13:10,282 --> 00:13:11,990
This is a pointer
machine data structure,

231
00:13:11,990 --> 00:13:14,340
it's not a binary search
tree, because binary search

232
00:13:14,340 --> 00:13:18,120
trees we only allowed to do walk
left, walk right, walk parent,

233
00:13:18,120 --> 00:13:20,470
But it's an easy way
to do dynamic finger.

234
00:13:20,470 --> 00:13:23,400
You start from
somewhere, you basically

235
00:13:23,400 --> 00:13:27,630
walk up to the right level,
move over, walk back down,

236
00:13:27,630 --> 00:13:33,840
and you can do a search for x
i from x i minus one relatively

237
00:13:33,840 --> 00:13:34,470
quickly.

238
00:13:34,470 --> 00:13:36,720
It turns out this can be
stimulated by a binary search

239
00:13:36,720 --> 00:13:38,970
tree, but we won't
go into it here.

240
00:13:38,970 --> 00:13:42,040
Lots of fun puzzles here.

241
00:13:42,040 --> 00:13:50,190
Let's move on to some
more bounds or properties.

242
00:13:58,320 --> 00:14:01,890
So, next property is called
the entropy property,

243
00:14:01,890 --> 00:14:04,010
or entropy bound.

244
00:14:04,010 --> 00:14:17,310
And it says if key k appears
p sub k fraction of the time,

245
00:14:17,310 --> 00:14:26,640
then I'd like to achieve
a bound of entropy p

246
00:14:26,640 --> 00:14:31,290
k log one over p
k per operation.

247
00:14:31,290 --> 00:14:34,072
This is, everything here
today will be amortized.

248
00:14:36,780 --> 00:14:39,905
So, if you haven't seen
entropy, that's the definition.

249
00:14:39,905 --> 00:14:41,970
It's the entropy of
this distribution.

250
00:14:41,970 --> 00:14:44,040
We're thinking of
these as probabilities,

251
00:14:44,040 --> 00:14:46,870
although they're not
really probabilities.

252
00:14:46,870 --> 00:14:51,150
They're, because this is
over a particular sample.

253
00:14:51,150 --> 00:14:54,670
We have this sequence x1 to x
n, There's no randomness here,

254
00:14:54,670 --> 00:14:56,610
but we just measure
what is the fraction,

255
00:14:56,610 --> 00:14:59,380
what is sort of the observed
probability for each of these x

256
00:14:59,380 --> 00:15:00,210
i's.

257
00:15:00,210 --> 00:15:03,120
And then just say,
what is the, what

258
00:15:03,120 --> 00:15:04,620
is the entropy of
that distribution?

259
00:15:04,620 --> 00:15:06,870
In the worst case
it's log n, if say

260
00:15:06,870 --> 00:15:09,640
everybody's equally likely,
everyone's accessed once,

261
00:15:09,640 --> 00:15:11,730
or the same number of times.

262
00:15:11,730 --> 00:15:14,130
But if it's highly
skewed, like if only one

263
00:15:14,130 --> 00:15:16,479
element is accessed, the
entropy will be constant.

264
00:15:16,479 --> 00:15:18,270
If a small number of
elements are accessed,

265
00:15:18,270 --> 00:15:19,311
entropy will be constant.

266
00:15:21,940 --> 00:15:24,090
So this can be
achieved, and in fact,

267
00:15:24,090 --> 00:15:27,270
if you disallow
rotations, so if I change

268
00:15:27,270 --> 00:15:29,700
the model to forbid
rotations, all I get to do

269
00:15:29,700 --> 00:15:31,740
is set up some
binary search tree,

270
00:15:31,740 --> 00:15:34,460
and then I have to walk left,
walk right, walk parent,

271
00:15:34,460 --> 00:15:37,680
from in that binary
search tree to do this.

272
00:15:37,680 --> 00:15:39,900
So if I get to
see the x i's then

273
00:15:39,900 --> 00:15:43,020
I get to build a
binary search tree.

274
00:15:43,020 --> 00:15:45,210
One binary search tree.

275
00:15:45,210 --> 00:15:47,160
This is what's called
the static optimal, when

276
00:15:47,160 --> 00:15:50,310
you're not allowed to change the
tree as you're doing searches.

277
00:15:50,310 --> 00:15:52,730
Entropy is the best
bound you can get.

278
00:15:52,730 --> 00:15:57,990
And roughly speaking, key k
appears at height, or depth,

279
00:15:57,990 --> 00:16:01,470
log one over p k in the
tree, maybe plus one.

280
00:16:01,470 --> 00:16:06,480
And you can show there's always
a tree where every node ends up

281
00:16:06,480 --> 00:16:08,580
at depth log one over p k.

282
00:16:08,580 --> 00:16:13,470
Again, not hard, but
we won't do it here.

283
00:16:13,470 --> 00:16:19,030
OK, a related property,
it's called the working set

284
00:16:19,030 --> 00:16:19,530
property.

285
00:16:28,770 --> 00:16:30,120
Little bit harder to state.

286
00:17:03,020 --> 00:17:06,290
For each search we
do x i, we're going

287
00:17:06,290 --> 00:17:10,970
to see when that's some key,
when was the last time that key

288
00:17:10,970 --> 00:17:12,180
was accessed.

289
00:17:12,180 --> 00:17:19,215
So, in our space-time diagram
we have some access at time i,

290
00:17:19,215 --> 00:17:21,980
we want to look backwards
in time to the last time

291
00:17:21,980 --> 00:17:24,319
that key was accessed.

292
00:17:24,319 --> 00:17:30,860
Say that was, well some other
time j, and in this interval

293
00:17:30,860 --> 00:17:36,560
we want to know, how many
distinct keys were accessed.

294
00:17:36,560 --> 00:17:41,060
So it's at most, i
minus j, but maybe there

295
00:17:41,060 --> 00:17:44,340
were some repeated accesses,
we only count those as one.

296
00:17:44,340 --> 00:17:46,970
So how many different
keys were accessed

297
00:17:46,970 --> 00:17:48,500
during that time interval?

298
00:17:48,500 --> 00:17:52,260
Claim is, we only have
to pay log of that.

299
00:17:52,260 --> 00:17:54,880
So what this means, what this
implies, is in particular,

300
00:17:54,880 --> 00:17:59,690
if you're only accessing say
k different elements at all,

301
00:17:59,690 --> 00:18:01,380
and you ignore all
the other elements,

302
00:18:01,380 --> 00:18:03,867
then you'll only pay
log k per operation.

303
00:18:03,867 --> 00:18:05,450
That's why it's sort
of a working set.

304
00:18:05,450 --> 00:18:06,825
If you're focusing
your attention

305
00:18:06,825 --> 00:18:10,430
on k elements for a
while, you only pay log k.

306
00:18:10,430 --> 00:18:12,860
But in general, for any access
sequence you can compute,

307
00:18:12,860 --> 00:18:14,360
what is the working
set costs, which

308
00:18:14,360 --> 00:18:17,540
is you sum over all
the i's of log t i,

309
00:18:17,540 --> 00:18:19,940
that is your total cost
for the access sequence.

310
00:18:19,940 --> 00:18:23,470
Divide by n, that's
the amortized cost.

311
00:18:23,470 --> 00:18:24,920
OK?

312
00:18:24,920 --> 00:18:26,390
That's another
nice property, not

313
00:18:26,390 --> 00:18:30,240
so obvious is that working
set implies the entropy bound,

314
00:18:30,240 --> 00:18:33,350
so this is a stronger property.

315
00:18:33,350 --> 00:18:36,800
I guess dynamic finger
implies sequential access,

316
00:18:36,800 --> 00:18:40,950
but there's no relation between
working set and dynamic finger.

317
00:18:40,950 --> 00:18:43,760
In fact, they're kind of
transposes of each other.

318
00:18:43,760 --> 00:18:46,030
Working set is
about, if you access

319
00:18:46,030 --> 00:18:49,520
a key that was accessed
recently, then it's fast.

320
00:18:49,520 --> 00:18:51,470
Dynamic finger is
saying, if you access

321
00:18:51,470 --> 00:18:56,330
a key that is close in space
to the previous access,

322
00:18:56,330 --> 00:18:59,240
so here we're looking
at a key and basically

323
00:18:59,240 --> 00:19:01,880
in the very previous
time step we're

324
00:19:01,880 --> 00:19:04,400
looking at how far
away it was vertically,

325
00:19:04,400 --> 00:19:07,100
here we're looking at how
far away it was horizontally.

326
00:19:07,100 --> 00:19:09,680
So they're almost
duals of each other.

327
00:19:09,680 --> 00:19:12,200
Be nice if you could
have one property that

328
00:19:12,200 --> 00:19:15,710
included both dynamic
finger and working set.

329
00:19:15,710 --> 00:19:17,810
I should mention, again
this is not obvious

330
00:19:17,810 --> 00:19:19,700
how to do it with a
binary search tree,

331
00:19:19,700 --> 00:19:21,570
but it can be done.

332
00:19:21,570 --> 00:19:22,840
Leave it at that.

333
00:19:22,840 --> 00:19:25,220
We'll see eventually
some trees that have it.

334
00:19:28,586 --> 00:19:29,960
For now I just
want to cover what

335
00:19:29,960 --> 00:19:32,940
are the conceivable
goals we should aim for.

336
00:19:32,940 --> 00:19:36,230
All right, log n is too easy, so
we need more challenging goals.

337
00:19:39,380 --> 00:19:41,870
So the next property,
it was introduced,

338
00:19:41,870 --> 00:19:48,710
this is we're getting into
more recent territory, 2001,

339
00:19:48,710 --> 00:19:50,870
it's called the
unified property.

340
00:19:50,870 --> 00:19:54,770
Natural name, and it tries
to unify dynamic finger

341
00:19:54,770 --> 00:19:57,560
with working set.

342
00:19:57,560 --> 00:19:59,330
And the rough idea
is, that if you

343
00:19:59,330 --> 00:20:02,630
access a key that
is close in space

344
00:20:02,630 --> 00:20:05,300
to a key that was
accessed recently in time,

345
00:20:05,300 --> 00:20:08,010
then your access should be fast.

346
00:20:08,010 --> 00:20:11,225
So, here's the formal statement.

347
00:20:56,790 --> 00:21:00,210
So here's the unified bound.

348
00:21:00,210 --> 00:21:03,060
Let's draw a picture.

349
00:21:03,060 --> 00:21:11,740
So here we're accessing
x i at time i, sorry j.

350
00:21:11,740 --> 00:21:14,430
Change of notation.

351
00:21:14,430 --> 00:21:14,930
Time j.

352
00:21:14,930 --> 00:21:18,260
We want to evaluate
the cost of x j,

353
00:21:18,260 --> 00:21:22,840
and we're basically
going to look in--

354
00:21:22,840 --> 00:21:26,750
I guess one way to think
of it is this cone.

355
00:21:26,750 --> 00:21:31,010
90 degree cone, where
these are 45 degree angles.

356
00:21:31,010 --> 00:21:33,590
And if there's something--

357
00:21:33,590 --> 00:21:37,310
and look at the first thing
that you hit in that cone.

358
00:21:37,310 --> 00:21:38,960
Is that the right
way to think of it?

359
00:21:38,960 --> 00:21:41,150
Maybe not.

360
00:21:41,150 --> 00:21:44,810
It's like you're growing a box,
this is probably more accurate,

361
00:21:44,810 --> 00:21:47,012
and you find the first key
that you hit in that box.

362
00:21:47,012 --> 00:21:48,470
It's a little more
subtle than that

363
00:21:48,470 --> 00:21:50,980
because we're only
counting distinct keys,

364
00:21:50,980 --> 00:21:55,130
and let's say you find this
key, and this key is good

365
00:21:55,130 --> 00:22:03,470
because it's temporal distance,
this time, is only this big.

366
00:22:03,470 --> 00:22:05,600
It's spatial distance
is only this big.

367
00:22:05,600 --> 00:22:08,600
What we're going to
pay is, log of the sum

368
00:22:08,600 --> 00:22:11,996
of the spatial distance,
and the temporal distance.

369
00:22:11,996 --> 00:22:13,370
And temporal
distance is measured

370
00:22:13,370 --> 00:22:16,640
as the number of distinct keys
accessed in this time interval.

371
00:22:19,560 --> 00:22:23,810
So, as long as there is some
key in the recent past that

372
00:22:23,810 --> 00:22:28,040
is close in space, you take
the min over all such keys,

373
00:22:28,040 --> 00:22:29,810
magically a unified
structure has

374
00:22:29,810 --> 00:22:33,050
to find what is the
most recent close item

375
00:22:33,050 --> 00:22:35,860
and search from there,
and achieve log of that.

376
00:22:35,860 --> 00:22:38,960
There's a plus 2 just to make
sure if these things are zero,

377
00:22:38,960 --> 00:22:41,180
you still get a constant.

378
00:22:41,180 --> 00:22:44,390
Always have to
pay constant time.

379
00:22:44,390 --> 00:22:46,970
OK, so that's a
unified property.

380
00:22:46,970 --> 00:22:51,380
Fairly natural generalization of
dynamic finger and working set.

381
00:22:51,380 --> 00:22:54,270
I mean you could change this
plus to a product or a max,

382
00:22:54,270 --> 00:22:55,727
doesn't make a difference.

383
00:22:59,070 --> 00:23:00,380
Yeah.

384
00:23:00,380 --> 00:23:01,760
Sadly we don't
know whether there

385
00:23:01,760 --> 00:23:05,720
is any binary search tree that
achieves the unified property.

386
00:23:05,720 --> 00:23:09,020
What we know is that
this can be done,

387
00:23:09,020 --> 00:23:15,140
this property can be achieved
by a pointer machine data

388
00:23:15,140 --> 00:23:18,001
structure, which is more
powerful than a binary search

389
00:23:18,001 --> 00:23:18,500
tree.

390
00:23:24,100 --> 00:23:29,060
But we don't know whether
it's possible to achieve

391
00:23:29,060 --> 00:23:32,390
by a binary search tree.

392
00:23:32,390 --> 00:23:36,470
Best bound so far, is
that you can achieve

393
00:23:36,470 --> 00:23:39,170
this bound plus log log n.

394
00:23:39,170 --> 00:23:41,725
So as long as this
never gets too small,

395
00:23:41,725 --> 00:23:44,430
as long as this quantity
never gets smaller than log n,

396
00:23:44,430 --> 00:23:47,066
then this thing will be
log log n, and it's fine.

397
00:23:47,066 --> 00:23:48,690
But in particular,
if this is constant,

398
00:23:48,690 --> 00:23:51,670
then it's only achieving
log log n, so it's not--

399
00:23:51,670 --> 00:23:55,230
there's an additive log
log n per operation loss.

400
00:23:55,230 --> 00:23:57,430
That's the best binary
search, unified binary search

401
00:23:57,430 --> 00:23:57,929
tree known.

402
00:24:00,520 --> 00:24:04,090
OK, so this is all good.

403
00:24:04,090 --> 00:24:08,030
And this is sort of where the,
what we call analytic bounds,

404
00:24:08,030 --> 00:24:10,610
here ends.

405
00:24:10,610 --> 00:24:12,002
There are various attempts to--

406
00:24:12,002 --> 00:24:13,460
in general we want
to characterize,

407
00:24:13,460 --> 00:24:17,720
what is the optimal
thing we could hope for.

408
00:24:17,720 --> 00:24:19,640
When can we do
better than log n?

409
00:24:19,640 --> 00:24:21,140
These are all
specific cases where

410
00:24:21,140 --> 00:24:22,848
we can do better than
log n, but it's not

411
00:24:22,848 --> 00:24:24,520
a complete characterization.

412
00:24:24,520 --> 00:24:27,410
There are sequences that
have large unified bound,

413
00:24:27,410 --> 00:24:29,165
but have no--

414
00:24:31,730 --> 00:24:33,740
yet they can be
accessed more quickly

415
00:24:33,740 --> 00:24:35,624
by the optimal
binary search tree.

416
00:24:35,624 --> 00:24:37,540
And so, while it would
be nice to characterize

417
00:24:37,540 --> 00:24:41,780
with some clean algebraic,
whatever, most of the work,

418
00:24:41,780 --> 00:24:43,970
beyond what I've
told you about here,

419
00:24:43,970 --> 00:24:46,400
is just trying to
figure out what opt is.

420
00:24:46,400 --> 00:24:50,259
Instead of trying to write
it down, try to compute it.

421
00:24:50,259 --> 00:24:51,800
Instead of trying
to define something

422
00:24:51,800 --> 00:24:53,690
that happens to
match the optimal,

423
00:24:53,690 --> 00:24:56,100
let's just go for optimal.

424
00:24:56,100 --> 00:24:58,433
And this is the notion
of dynamic optimality.

425
00:25:02,510 --> 00:25:04,090
And in modern
terminology this would

426
00:25:04,090 --> 00:25:09,860
be called constant
competitive, but the paper then

427
00:25:09,860 --> 00:25:13,145
introduced dynamic optimality
preceded competitive analysis,

428
00:25:13,145 --> 00:25:15,980
so it has another name.

429
00:25:15,980 --> 00:25:19,550
What we'd like, is that
the total cost of all

430
00:25:19,550 --> 00:25:22,530
your accesses, so this
is like amortized cost,

431
00:25:22,530 --> 00:25:26,920
is within a constant
factor of the optimal.

432
00:25:26,920 --> 00:25:29,240
What's the optimal?

433
00:25:29,240 --> 00:25:33,080
This is the-- over all
binary search trees,

434
00:25:33,080 --> 00:25:35,720
I mean to be precise I should
talk about binary search tree

435
00:25:35,720 --> 00:25:39,500
algorithms, meaning you specify
somehow how to do a search,

436
00:25:39,500 --> 00:25:41,900
and it may involve
rotations and walks.

437
00:25:41,900 --> 00:25:44,510
So, you know, it could
be red black tree,

438
00:25:44,510 --> 00:25:46,700
it could be an AVL tree,
could be a [? BB ?] alpha

439
00:25:46,700 --> 00:25:49,640
tree, anything that can be
implemented in this way.

440
00:25:49,640 --> 00:25:52,330
Those are all kind of boring.

441
00:25:52,330 --> 00:25:55,850
More sophisticated is
something like a splay tree.

442
00:25:55,850 --> 00:25:59,915
Ideally, you take
the min over all--

443
00:26:02,840 --> 00:26:06,710
min over all binary
search tree algorithms.

444
00:26:06,710 --> 00:26:13,820
The cost of that algorithm, on
that access sequence x, and you

445
00:26:13,820 --> 00:26:15,740
want the total cost
of your algorithm

446
00:26:15,740 --> 00:26:19,760
on x to be within a constant
factor of the optimal algorithm

447
00:26:19,760 --> 00:26:20,780
on x.

448
00:26:20,780 --> 00:26:23,610
x is a vector.

449
00:26:23,610 --> 00:26:26,540
So this is what you call
the offline optimal,

450
00:26:26,540 --> 00:26:29,600
because here you basically get
to choose the binary search

451
00:26:29,600 --> 00:26:33,800
tree algorithm to
be customized to x,

452
00:26:33,800 --> 00:26:40,310
and yet somehow you want to
achieve dynamic optimality.

453
00:26:40,310 --> 00:26:43,970
Open question, is this possible?

454
00:26:53,990 --> 00:26:57,330
And, of course, we're only
interested in online solutions.

455
00:26:57,330 --> 00:26:59,432
So, you want to build a
binary search tree that

456
00:26:59,432 --> 00:27:00,890
doesn't know the
future, it doesn't

457
00:27:00,890 --> 00:27:02,750
know what accesses
are to come, but it

458
00:27:02,750 --> 00:27:06,020
has to be within a constant
factor of the offline solution

459
00:27:06,020 --> 00:27:07,928
that does know.

460
00:27:07,928 --> 00:27:10,160
And we don't know
whether this is possible.

461
00:27:10,160 --> 00:27:12,530
Another interesting
question, is whether it's

462
00:27:12,530 --> 00:27:17,634
possible for a pointer
machine, because save

463
00:27:17,634 --> 00:27:19,550
for the unified property
we know how to get it

464
00:27:19,550 --> 00:27:21,980
for a pointer machine.

465
00:27:21,980 --> 00:27:23,730
And there's two versions
of this question.

466
00:27:23,730 --> 00:27:25,970
You can consider, is
there a pointer machine

467
00:27:25,970 --> 00:27:28,096
that matches the optimal
binary search tree,

468
00:27:28,096 --> 00:27:30,470
or you could ask, is there a
pointer machine that matches

469
00:27:30,470 --> 00:27:31,779
the optimal pointer machine.

470
00:27:31,779 --> 00:27:34,070
That's a little less defined,
although there are some--

471
00:27:34,070 --> 00:27:36,528
I have some ideas on how to
define that problem, maybe will

472
00:27:36,528 --> 00:27:37,460
work on it.

473
00:27:37,460 --> 00:27:41,360
But all versions of this
problem are open, basically.

474
00:27:41,360 --> 00:27:43,580
So, this may seem
rather depressing.

475
00:27:43,580 --> 00:27:46,472
What else am I going to do
for a lecture and a half?

476
00:27:46,472 --> 00:27:48,680
But actually, there's a lot
of study of this problem,

477
00:27:48,680 --> 00:27:50,013
and we do know some good things.

478
00:27:50,013 --> 00:27:56,907
For example, we can get
log log n competitive.

479
00:28:00,890 --> 00:28:02,540
So, not within a
constant factor,

480
00:28:02,540 --> 00:28:06,480
but we can get within a log
log n factor of the optimal.

481
00:28:06,480 --> 00:28:07,785
So, that's pretty good.

482
00:28:07,785 --> 00:28:11,644
An easy result is to
get log n competitive.

483
00:28:11,644 --> 00:28:13,310
Any balanced binary
search tree is log n

484
00:28:13,310 --> 00:28:16,070
competitive, because best case
you could hope for is constant,

485
00:28:16,070 --> 00:28:18,160
the worst case you
can hope for is log n.

486
00:28:18,160 --> 00:28:19,962
So at least within
the log factor,

487
00:28:19,962 --> 00:28:21,420
but we can do
exponentially better.

488
00:28:21,420 --> 00:28:24,560
We'll do that next class.

489
00:28:24,560 --> 00:28:31,820
Before we go there, I want to
tell you about two structures,

490
00:28:31,820 --> 00:28:36,110
to binary search trees that
we conjecture are dynamically

491
00:28:36,110 --> 00:28:38,030
optimal, but we can't prove it.

492
00:29:01,300 --> 00:29:03,890
So first one, and the classic
one, is splayed trees.

493
00:29:03,890 --> 00:29:06,790
I don't want to spend too
much time on splay trees,

494
00:29:06,790 --> 00:29:09,920
but just to let you know what
they are if you don't already

495
00:29:09,920 --> 00:29:11,270
know.

496
00:29:11,270 --> 00:29:14,900
If you want to search
for x, you search for x.

497
00:29:14,900 --> 00:29:17,750
You do a binary search
for x in the tree.

498
00:29:17,750 --> 00:29:19,930
You locate x, and then you--

499
00:29:19,930 --> 00:29:24,270
splay trees always
move x to the root.

500
00:29:24,270 --> 00:29:27,230
So, this is what we call
a self-adjusting tree.

501
00:29:27,230 --> 00:29:30,170
It changes the structure of
the tree as you do searches,

502
00:29:30,170 --> 00:29:34,160
not just when you're
doing updates,

503
00:29:34,160 --> 00:29:36,570
and there are two cases.

504
00:29:36,570 --> 00:29:39,200
If you look at x, and its
parent and its grandparent,

505
00:29:39,200 --> 00:29:40,650
if they're oriented
the same way.

506
00:29:40,650 --> 00:29:44,180
So, here it's two left pointers,
could be two right pointers.

507
00:29:44,180 --> 00:29:46,850
Then you flip them.

508
00:29:46,850 --> 00:29:57,660
So we rotate y, and then rotate
x, so it's in this model.

509
00:29:57,660 --> 00:30:02,660
And we get x y z
in the other order.

510
00:30:02,660 --> 00:30:04,610
There's pretty much
only one way to move

511
00:30:04,610 --> 00:30:06,170
x to the root in that picture.

512
00:30:09,020 --> 00:30:17,255
Then the other case is
the zigzag case, y, w, x.

513
00:30:20,330 --> 00:30:22,890
So, here the two parent pointers
are in different directions,

514
00:30:22,890 --> 00:30:24,530
one is left, one is right.

515
00:30:24,530 --> 00:30:26,520
There's a symmetric picture.

516
00:30:26,520 --> 00:30:29,760
In this case, we rotate
in the other order.

517
00:30:29,760 --> 00:30:32,900
So, we rotate x, and
then we rotate y.

518
00:30:35,930 --> 00:30:44,465
And in that case you get x
nice, x, w, y, and the subtrees

519
00:30:44,465 --> 00:30:45,015
hang off.

520
00:30:45,015 --> 00:30:46,640
I'm not labeling the
subtrees, but they

521
00:30:46,640 --> 00:30:50,940
have to be labeled in the
same order, left to right.

522
00:30:50,940 --> 00:30:52,130
OK, this is splay trees.

523
00:30:52,130 --> 00:30:56,360
You do this for x. x is
the thing you search for,

524
00:30:56,360 --> 00:30:58,460
now x is up here,
then you repeat.

525
00:30:58,460 --> 00:31:01,410
You look at it's two parents,
it's one of these two cases,

526
00:31:01,410 --> 00:31:03,650
you do the appropriate
two rotations.

527
00:31:03,650 --> 00:31:05,662
Until x is either the
root, and you're done,

528
00:31:05,662 --> 00:31:07,370
or it's one child from
the root, and then

529
00:31:07,370 --> 00:31:09,036
you do one rotation
to make it the root.

530
00:31:12,040 --> 00:31:14,120
Seems simple enough.

531
00:31:14,120 --> 00:31:17,290
It's slightly more sophisticated
than an algorithm known as move

532
00:31:17,290 --> 00:31:19,780
to root, which is just
rotate x, rotate x,

533
00:31:19,780 --> 00:31:22,450
rotate x, which would
eventually propagate it up.

534
00:31:22,450 --> 00:31:24,190
Move to root is a
really bad algorithm.

535
00:31:24,190 --> 00:31:26,770
It can show its can be a
factor of square root of n.

536
00:31:26,770 --> 00:31:30,760
It can be square root of n per
operation if you're unlucky.

537
00:31:30,760 --> 00:31:34,510
Splay trees are always, at most
log n amortized per operation,

538
00:31:34,510 --> 00:31:36,310
although that's
not at all obvious.

539
00:31:36,310 --> 00:31:39,670
Rough intuition, is if you
look at the path, the route

540
00:31:39,670 --> 00:31:44,740
to x path, half of the nodes,
at most half of the nodes

541
00:31:44,740 --> 00:31:47,650
go down when you splay.

542
00:31:47,650 --> 00:31:49,030
So why is that?

543
00:31:49,030 --> 00:31:52,250
Here, see y stays
at the same level.

544
00:31:52,250 --> 00:31:55,150
z goes down, but x goes up.

545
00:31:55,150 --> 00:32:00,710
Here, w stays at the same level,
x goes up, y goes down by one,

546
00:32:00,710 --> 00:32:04,060
x goes up by two, so you might
call that a net improvement.

547
00:32:04,060 --> 00:32:06,940
But in general you don't
mess up the path too much.

548
00:32:06,940 --> 00:32:09,320
Half the items stay
where they are,

549
00:32:09,320 --> 00:32:12,400
and so it's something
like your bisecting--

550
00:32:12,400 --> 00:32:14,155
if you repeatedly
search for x, well

551
00:32:14,155 --> 00:32:16,090
I'm not really searching
for x, but if you repeatedly

552
00:32:16,090 --> 00:32:17,673
search for things
in that path, you're

553
00:32:17,673 --> 00:32:19,550
kind of cutting the path
and half repeatedly.

554
00:32:19,550 --> 00:32:23,710
It'll look kind of logarithmic,
that's a very vague argument.

555
00:32:23,710 --> 00:32:25,930
And in the advanced
algorithms, it's

556
00:32:25,930 --> 00:32:27,790
proved why this is
log n amortized.

557
00:32:27,790 --> 00:32:28,707
Question?

558
00:32:28,707 --> 00:32:35,180
AUDIENCE: [INAUDIBLE]

559
00:32:35,180 --> 00:32:38,350
PROFESSOR: Rotate x, rotate
x, I think you're right.

560
00:32:38,350 --> 00:32:42,390
Yeah, y would go
somewhere else, thanks.

561
00:32:42,390 --> 00:32:48,580
Yeah, so here it looks like
move to root, here it doesn't.

562
00:32:48,580 --> 00:32:52,430
Good, and there's lots of
things known about splay trees.

563
00:32:52,430 --> 00:32:56,580
So for example, they satisfy
the sequential access property.

564
00:32:56,580 --> 00:33:00,380
There's an entire paper,
combinatoric on 1985 Tarjan

565
00:33:00,380 --> 00:33:03,860
I believe, proving splay trees
have the sequential access

566
00:33:03,860 --> 00:33:04,460
property.

567
00:33:04,460 --> 00:33:08,120
Not at all obvious,
but it's true.

568
00:33:08,120 --> 00:33:10,040
They have the
working set property,

569
00:33:10,040 --> 00:33:12,400
and therefore they have
the entropy property.

570
00:33:12,400 --> 00:33:14,154
That's in the original
splay tree paper.

571
00:33:14,154 --> 00:33:15,320
It's not that hard to prove.

572
00:33:15,320 --> 00:33:17,840
Once you prove log n, with
a little bit more effort

573
00:33:17,840 --> 00:33:19,550
you can prove the
working set property.

574
00:33:19,550 --> 00:33:21,890
We won't do it here.

575
00:33:21,890 --> 00:33:26,660
It's a cool amortization.

576
00:33:26,660 --> 00:33:29,690
Splay trees also have the
dynamic finger property.

577
00:33:29,690 --> 00:33:33,410
This is a series of two
papers, over 100 pages long.

578
00:33:33,410 --> 00:33:34,660
Very difficult to prove.

579
00:33:34,660 --> 00:33:36,620
In general, splay trees
are hard to work with,

580
00:33:36,620 --> 00:33:39,392
because it's hard to keep
track of what's going on.

581
00:33:39,392 --> 00:33:40,850
You can define
potential functions,

582
00:33:40,850 --> 00:33:43,070
and that will prove this,
and with a lot of effort

583
00:33:43,070 --> 00:33:44,480
it will prove this.

584
00:33:44,480 --> 00:33:46,430
We don't know whether
splay trees satisfy

585
00:33:46,430 --> 00:33:48,364
the unified property,
and more to the point,

586
00:33:48,364 --> 00:33:50,780
we don't know whether splay
trees are dynamically optimal.

587
00:33:50,780 --> 00:33:53,900
This is the big question, and
in the original splay tree paper

588
00:33:53,900 --> 00:33:56,210
it asked this question,
are splay trees

589
00:33:56,210 --> 00:33:57,590
dynamically optimal.

590
00:33:57,590 --> 00:34:01,700
Still open, I wish I knew
the answer, but we don't.

591
00:34:05,390 --> 00:34:08,139
So what the rest of today's
lecture is going to be about

592
00:34:08,139 --> 00:34:12,747
is a geometric view, which
I've kind of been hinting

593
00:34:12,747 --> 00:34:14,830
at with this picture, but
it's, there's more to it

594
00:34:14,830 --> 00:34:18,580
than just plot the
points of searches.

595
00:34:18,580 --> 00:34:21,159
There's a way, not only to
see what the searches are,

596
00:34:21,159 --> 00:34:24,902
but to see what the binary
search tree algorithm is.

597
00:34:24,902 --> 00:34:26,860
So, at this point binary
search tree algorithms

598
00:34:26,860 --> 00:34:28,090
are kind of abstract.

599
00:34:28,090 --> 00:34:29,980
I mean, we've kind
of drawn pictures,

600
00:34:29,980 --> 00:34:31,810
and how to do
specific cases, you

601
00:34:31,810 --> 00:34:34,850
know how red black
trees or something work.

602
00:34:34,850 --> 00:34:36,790
But, you know, it's
complicated to write down

603
00:34:36,790 --> 00:34:37,789
one of these algorithms.

604
00:34:37,789 --> 00:34:41,050
How would we think
about all of them?

605
00:34:41,050 --> 00:34:43,120
What would you think
about the optimal one?

606
00:34:43,120 --> 00:34:45,940
Turns out there's a geometric
view, in which it's actually

607
00:34:45,940 --> 00:34:48,790
very easy to see what
the algorithm is,

608
00:34:48,790 --> 00:34:50,500
but it takes a
little bit of work

609
00:34:50,500 --> 00:34:52,750
to prove that it's
the right thing.

610
00:34:52,750 --> 00:34:57,820
And it suggests a totally
obvious offline optimal

611
00:34:57,820 --> 00:35:00,850
algorithm, which we
don't know is optimal,

612
00:35:00,850 --> 00:35:03,940
but we think is offline optimal.

613
00:35:03,940 --> 00:35:10,150
It's like the obvious thing
to do, which we'll get to,

614
00:35:10,150 --> 00:35:12,100
and we can actually
make it online.

615
00:35:12,100 --> 00:35:14,350
So, this is-- this
gives us a binary search

616
00:35:14,350 --> 00:35:17,110
tree that is so
obviously optimal,

617
00:35:17,110 --> 00:35:20,440
where splay trees is kind
of vaguely feels good,

618
00:35:20,440 --> 00:35:23,275
this is really obvious,
yet we can't prove it.

619
00:35:23,275 --> 00:35:26,710
So it's like we're one step
closer, but not quite there.

620
00:35:29,594 --> 00:35:30,760
So that's where we're going.

621
00:35:56,550 --> 00:35:59,250
So this geometric view was
the topic of [? Deion ?]

622
00:35:59,250 --> 00:36:01,740
[? Harmon's ?] PhD
thesis, here at MIT.

623
00:36:01,740 --> 00:36:04,717
And it's also with John Iacono,
[? Danielle ?] [? Caine, ?] who

624
00:36:04,717 --> 00:36:07,050
was an undergrad here, and
[? Mihal ?] [? Piotrowski, ?]

625
00:36:07,050 --> 00:36:09,450
who was an undergrad
and a PhD here.

626
00:36:09,450 --> 00:36:13,890
It was published
three years ago, 2009.

627
00:36:13,890 --> 00:36:17,130
So, here's the idea.

628
00:36:17,130 --> 00:36:21,780
Access sequence, this is the
sequence of searches you do.

629
00:36:21,780 --> 00:36:26,970
That's very easy, you just
map it to the set of points

630
00:36:26,970 --> 00:36:29,910
where, I guess I'm going
to switch things on you.

631
00:36:29,910 --> 00:36:33,030
Sorry about that.

632
00:36:33,030 --> 00:36:38,280
X-axis is going to be space,
y-axis is going to be time.

633
00:36:38,280 --> 00:36:40,470
And I'm going to look at a
specific example of this.

634
00:36:44,720 --> 00:36:47,150
Sort of pinwheel.

635
00:36:47,150 --> 00:36:49,820
Four accesses at--
the first time

636
00:36:49,820 --> 00:36:52,640
we access key three, then
we access key one, then

637
00:36:52,640 --> 00:36:54,680
key four, then key two.

638
00:36:54,680 --> 00:36:57,710
We've been drawing this
picture throughout the lecture.

639
00:36:57,710 --> 00:37:02,090
Now the interesting part, is
if you look at a binary search

640
00:37:02,090 --> 00:37:06,870
tree that actually
accesses these elements,

641
00:37:06,870 --> 00:37:08,900
here's the exciting part.

642
00:37:08,900 --> 00:37:14,360
We're going to map this
to a point set, which

643
00:37:14,360 --> 00:37:29,570
is which nodes get
touched during a search,

644
00:37:29,570 --> 00:37:30,800
during each search.

645
00:37:37,720 --> 00:37:40,530
OK, this is the fun part.

646
00:37:40,530 --> 00:37:41,730
So, what does touched mean?

647
00:37:41,730 --> 00:37:45,205
I erased the model, but in
general with a binary search

648
00:37:45,205 --> 00:37:47,080
tree, we only have one
pointer into the tree.

649
00:37:47,080 --> 00:37:49,890
It starts at the root, it
can go left, it can go right,

650
00:37:49,890 --> 00:37:51,570
it can go to the parent.

651
00:37:51,570 --> 00:37:53,820
Every node that gets
visited during-- it

652
00:37:53,820 --> 00:37:55,980
can do rotations,
every node that

653
00:37:55,980 --> 00:38:01,590
gets visited by walking, that's
what I call a touched node.

654
00:38:01,590 --> 00:38:03,070
Just look at all of them.

655
00:38:03,070 --> 00:38:05,175
So for example,
in this picture--

656
00:38:11,260 --> 00:38:14,920
color-- suppose,
maybe we're lucky,

657
00:38:14,920 --> 00:38:17,090
and key three is at the root.

658
00:38:17,090 --> 00:38:20,390
So that's the only
thing I touch.

659
00:38:20,390 --> 00:38:22,772
If that's the case,
when I access one,

660
00:38:22,772 --> 00:38:23,980
it's definitely not the root.

661
00:38:23,980 --> 00:38:29,310
So, in particular, I definitely
have to have touched that node.

662
00:38:29,310 --> 00:38:36,370
And I'm just going to fill
in a reasonable choice.

663
00:38:36,370 --> 00:38:40,310
I happen to know, this is
a valid binary search tree.

664
00:38:40,310 --> 00:38:42,910
Not so obvious, but
you can find one.

665
00:38:42,910 --> 00:38:45,320
I'm using here, the
greedy algorithm actually,

666
00:38:45,320 --> 00:38:46,690
I'm cheating.

667
00:38:46,690 --> 00:38:49,460
We'll get to what that is.

668
00:38:49,460 --> 00:38:52,060
But in general, some point
sets, like this point set,

669
00:38:52,060 --> 00:38:53,500
are not valid.

670
00:38:53,500 --> 00:38:56,020
There's no binary search tree
that has this touch pattern.

671
00:38:56,020 --> 00:38:57,790
You just can't jump
around, teleport,

672
00:38:57,790 --> 00:39:01,490
without getting somewhere.

673
00:39:01,490 --> 00:39:02,740
But, this one is valid.

674
00:39:02,740 --> 00:39:04,029
So, which ones are valid?

675
00:39:04,029 --> 00:39:05,320
Oh sorry I need one more point.

676
00:39:08,726 --> 00:39:10,600
Which ones are valid,
which ones are invalid?

677
00:39:10,600 --> 00:39:12,160
How did I know that
that was invalid,

678
00:39:12,160 --> 00:39:14,150
and now this one is valid?

679
00:39:14,150 --> 00:39:16,440
Well, there's a
theorem tell you.

680
00:39:16,440 --> 00:39:19,870
Then what I was just doing
there will become clear.

681
00:39:36,970 --> 00:39:41,940
So, I want to know when is
the point set a valid BST

682
00:39:41,940 --> 00:39:47,850
execution, and I claim
it is, if and only

683
00:39:47,850 --> 00:40:07,530
if, in every rectangle
spanned by two points

684
00:40:07,530 --> 00:40:26,160
not on a common horizontal
or vertical line,

685
00:40:26,160 --> 00:40:28,650
in every rectangle, there
there's another point.

686
00:40:37,710 --> 00:40:39,390
So, let me draw a picture.

687
00:40:39,390 --> 00:40:41,200
I have some point set.

688
00:40:41,200 --> 00:40:43,200
We'll look at this
one in a moment.

689
00:40:43,200 --> 00:40:44,940
In general, I take
any two points

690
00:40:44,940 --> 00:40:47,640
that are not horizontally
or vertically aligned,

691
00:40:47,640 --> 00:40:50,187
that spans a rectangle.

692
00:40:50,187 --> 00:40:52,020
In other words, the
rectangle with those two

693
00:40:52,020 --> 00:40:53,850
as opposite corners.

694
00:40:53,850 --> 00:40:56,082
There's got to be another
point in there, somewhere.

695
00:40:56,082 --> 00:40:57,915
Could be on the boundary,
could be interior.

696
00:41:00,490 --> 00:41:02,770
OK, in fact, you can
pump this a little bit.

697
00:41:02,770 --> 00:41:05,880
So once I find some point,
let's say on the interior,

698
00:41:05,880 --> 00:41:09,480
then my picture looks like this.

699
00:41:09,480 --> 00:41:12,970
Maybe I'll just
draw it as a circle.

700
00:41:12,970 --> 00:41:14,670
Well, here's another rectangle.

701
00:41:14,670 --> 00:41:16,500
That one has to have
a point inside it.

702
00:41:16,500 --> 00:41:18,090
Here's another
rectangle, that one

703
00:41:18,090 --> 00:41:20,410
has to have a point inside it.

704
00:41:20,410 --> 00:41:25,590
You could keep going, until you
know maybe I'd put one here,

705
00:41:25,590 --> 00:41:27,760
maybe I put one here.

706
00:41:27,760 --> 00:41:30,000
OK if I update the
picture then, I still

707
00:41:30,000 --> 00:41:33,410
have a little
rectangle like that,

708
00:41:33,410 --> 00:41:36,600
little rectangle like that,
little rectangle like this.

709
00:41:36,600 --> 00:41:38,760
At this point, this point
is no longer involved

710
00:41:38,760 --> 00:41:41,749
in any rectangles
essentially, because there's

711
00:41:41,749 --> 00:41:43,290
no rectangle between
these two points

712
00:41:43,290 --> 00:41:45,480
because they're
horizontally aligned.

713
00:41:45,480 --> 00:41:50,490
I could finish this off,
finally, by adding points,

714
00:41:50,490 --> 00:41:52,350
let's say at the corners.

715
00:41:52,350 --> 00:41:55,860
Once I add points at the
corners this will be satisfied.

716
00:41:55,860 --> 00:41:59,715
We call this property
arborally satisfied.

717
00:41:59,715 --> 00:42:01,770
Gotta look up the spelling.

718
00:42:01,770 --> 00:42:06,420
Arboral satisfaction.

719
00:42:06,420 --> 00:42:10,170
Arboral means having
to do with a tree.

720
00:42:10,170 --> 00:42:13,560
OK, so this is saying that
point set is treelike,

721
00:42:13,560 --> 00:42:15,570
if it has this property.

722
00:42:15,570 --> 00:42:17,490
OK this picture is
getting a little messy,

723
00:42:17,490 --> 00:42:23,460
but if I have any monotone path,
like this, this is satisfied.

724
00:42:23,460 --> 00:42:27,420
If you look at any rectangle,
say this one, it has points--

725
00:42:27,420 --> 00:42:29,170
other points in it.

726
00:42:29,170 --> 00:42:31,580
OK, if I look at, I
don't know, this one,

727
00:42:31,580 --> 00:42:32,910
it has another point in it.

728
00:42:32,910 --> 00:42:35,493
But look at this one, that one
doesn't count because it's just

729
00:42:35,493 --> 00:42:36,420
a vertical line.

730
00:42:36,420 --> 00:42:39,055
So it has to have non-zero area.

731
00:42:39,055 --> 00:42:41,970
If you look at any two
points, this one and this one,

732
00:42:41,970 --> 00:42:44,340
they span a rectangle, there's
another point in there.

733
00:42:44,340 --> 00:42:46,030
So, monotone paths are good.

734
00:42:46,030 --> 00:42:47,040
This point set.

735
00:42:47,040 --> 00:42:50,900
If I drew it correctly, is good.

736
00:42:50,900 --> 00:42:54,480
I look at any rectangle here,
it's got another point in it.

737
00:42:58,680 --> 00:43:02,670
Takes some practice to be able
to see all the rectangles,

738
00:43:02,670 --> 00:43:04,134
but check it.

739
00:43:04,134 --> 00:43:05,300
Eventually this one is good.

740
00:43:05,300 --> 00:43:06,341
This one's obviously bad.

741
00:43:06,341 --> 00:43:08,940
It has lots of wrecked-- we
call these empty rectangles,

742
00:43:08,940 --> 00:43:12,480
unsatisfied rectangles, that
have no extra points in them.

743
00:43:12,480 --> 00:43:15,772
So, this is a valid BST
execution, this is not.

744
00:43:15,772 --> 00:43:17,980
Let's prove this theorem
it's actually not that hard.

745
00:43:31,470 --> 00:43:33,740
The consequence
of the theorem, is

746
00:43:33,740 --> 00:43:37,440
it tells us what we need to do.

747
00:43:37,440 --> 00:43:39,440
We are given a
point set like this,

748
00:43:39,440 --> 00:43:42,960
we want a point set like this.

749
00:43:42,960 --> 00:43:47,510
We can define the cost
of a binary search tree

750
00:43:47,510 --> 00:43:49,640
to be how many
nodes does it touch.

751
00:43:49,640 --> 00:43:52,890
That's within a constant factor
of how many operations you do.

752
00:43:52,890 --> 00:43:54,920
If you don't want to,
it's pointless to touch

753
00:43:54,920 --> 00:43:56,930
a node more than a
constant number of times.

754
00:43:56,930 --> 00:43:58,220
You can prove that.

755
00:43:58,220 --> 00:44:02,060
So, really we just care about
how many nodes get touched.

756
00:44:02,060 --> 00:44:05,360
So, what we want to do is find
a minimum superset of this point

757
00:44:05,360 --> 00:44:08,150
set that is satisfied.

758
00:44:08,150 --> 00:44:10,230
We're given a set to
represent or access

759
00:44:10,230 --> 00:44:12,042
sequence that is not satisfied.

760
00:44:12,042 --> 00:44:14,000
We need to act-- we need
to touch those points.

761
00:44:14,000 --> 00:44:16,400
That's the definition of search.

762
00:44:16,400 --> 00:44:19,010
And now we'd just like to also
touch some other points that

763
00:44:19,010 --> 00:44:19,760
make it satisfied.

764
00:44:19,760 --> 00:44:24,050
This is a geometric
interpretation of dynamic opt.

765
00:44:24,050 --> 00:44:27,152
Can you find the
offline optimal, is--

766
00:44:27,152 --> 00:44:28,610
what's the minimum
number of points

767
00:44:28,610 --> 00:44:33,560
to add in order to make your
point set arborally satisfied.

768
00:44:33,560 --> 00:44:35,600
We don't know whether
that problem is NP hard.

769
00:44:35,600 --> 00:44:37,400
Probably it is.

770
00:44:37,400 --> 00:44:40,069
We don't know how to compute it.

771
00:44:40,069 --> 00:44:41,860
We don't know how to
find a constant factor

772
00:44:41,860 --> 00:44:44,690
approximation, unfortunately.

773
00:44:44,690 --> 00:44:45,882
Yeah?

774
00:44:45,882 --> 00:44:50,450
AUDIENCE: So, this is for and
access sequence, so every time

775
00:44:50,450 --> 00:44:53,399
corresponds to just
seeking like one

776
00:44:53,399 --> 00:44:54,690
individually thing in the tree?

777
00:44:54,690 --> 00:44:55,410
PROFESSOR: Right.

778
00:44:55,410 --> 00:44:56,210
AUDIENCE: OK, that
makes more sense.

779
00:44:56,210 --> 00:44:58,080
PROFESSOR: Yes, so the input--

780
00:44:58,080 --> 00:45:01,370
there is a unique
thing, a key, that

781
00:45:01,370 --> 00:45:03,060
gets accessed at each time.

782
00:45:03,060 --> 00:45:07,250
So if you draw any horizontal
line, in the input point

783
00:45:07,250 --> 00:45:09,560
set there's only one point
in each horizontal line.

784
00:45:09,560 --> 00:45:12,680
There can be multiple points
in each vertical line, which

785
00:45:12,680 --> 00:45:15,436
would mean that key gets
accessed more than one time.

786
00:45:15,436 --> 00:45:17,060
That's the obvious
interpretation terms

787
00:45:17,060 --> 00:45:19,435
of binary search tree, turns
out you don't need to assume

788
00:45:19,435 --> 00:45:20,780
either of those things.

789
00:45:20,780 --> 00:45:22,790
You could allow a
sort of multi-search,

790
00:45:22,790 --> 00:45:26,870
where I say during this round
you have to access key 5 and 7,

791
00:45:26,870 --> 00:45:28,730
I don't care in what order.

792
00:45:28,730 --> 00:45:31,010
Whereas normally I say,
you have access key 5,

793
00:45:31,010 --> 00:45:32,544
then you have to access key 7.

794
00:45:32,544 --> 00:45:33,960
You could do a
multi-search, where

795
00:45:33,960 --> 00:45:36,920
there's multiple
points in a single row.

796
00:45:36,920 --> 00:45:39,260
All of the things I'll say
work, it doesn't really

797
00:45:39,260 --> 00:45:41,450
make a difference as the claim.

798
00:45:41,450 --> 00:45:45,740
You could also assume that no
key is accessed more than once,

799
00:45:45,740 --> 00:45:47,270
so then there's only one--

800
00:45:47,270 --> 00:45:48,860
those would be the
opposite extreme.

801
00:45:48,860 --> 00:45:51,809
You can assume there's
only one key per column.

802
00:45:51,809 --> 00:45:53,600
That turns out not to
make much difference.

803
00:45:53,600 --> 00:45:55,700
If there's multiple keys
in the same position,

804
00:45:55,700 --> 00:45:58,220
just spread them out
a little and you'll

805
00:45:58,220 --> 00:46:00,960
get roughly the same cost.

806
00:46:00,960 --> 00:46:02,186
So, good question.

807
00:46:02,186 --> 00:46:03,560
But in the natural
interpretation

808
00:46:03,560 --> 00:46:05,268
there's one per row,
multiple per column,

809
00:46:05,268 --> 00:46:06,980
but it doesn't,
neither one matters.

810
00:46:09,855 --> 00:46:10,355
OK.

811
00:46:14,210 --> 00:46:17,360
So this becomes the problem,
go from this to this,

812
00:46:17,360 --> 00:46:20,630
with a minimum number
of added points.

813
00:46:20,630 --> 00:46:24,130
We do know a log log n
approximation to that problem.

814
00:46:24,130 --> 00:46:26,540
That's the best we know.

815
00:46:26,540 --> 00:46:29,000
You just take this
binary search tree,

816
00:46:29,000 --> 00:46:33,170
and apply this transformation,
and it tells you

817
00:46:33,170 --> 00:46:34,640
if you have a
binary search tree,

818
00:46:34,640 --> 00:46:37,022
you can turn it into a way
to satisfy a point set.

819
00:46:37,022 --> 00:46:39,230
But this is actually the
best approximation algorithm

820
00:46:39,230 --> 00:46:40,460
that we know.

821
00:46:40,460 --> 00:46:44,060
But as you'll see, the geometric
view offers a lot of insight.

822
00:46:44,060 --> 00:46:45,870
Gives us a lot of
power, and in some sense

823
00:46:45,870 --> 00:46:49,710
we use it to construct this.

824
00:46:49,710 --> 00:46:53,485
OK, so let's prove the theorem.

825
00:47:01,360 --> 00:47:02,660
So there's two directions.

826
00:47:02,660 --> 00:47:04,670
We'll start with
the easy direction.

827
00:47:04,670 --> 00:47:06,620
If you have a
binary search tree,

828
00:47:06,620 --> 00:47:09,404
then it must be
arborally satisfied.

829
00:47:09,404 --> 00:47:10,820
Then we'll have
to do the reverse,

830
00:47:10,820 --> 00:47:13,190
actually build a binary search
tree out of a point set.

831
00:47:13,190 --> 00:47:17,120
That's kind of the harder step.

832
00:47:17,120 --> 00:47:19,670
So, let's say we
have two points.

833
00:47:22,610 --> 00:47:27,860
Let's say this is that
time i, we access key x,

834
00:47:27,860 --> 00:47:31,610
and this one is at time
j, we access key y.

835
00:47:31,610 --> 00:47:33,340
Let's suppose y
is greater than x,

836
00:47:33,340 --> 00:47:35,990
there's the symmetric picture.

837
00:47:35,990 --> 00:47:38,270
We want to argue that
there is some other point

838
00:47:38,270 --> 00:47:42,010
in this rectangle.

839
00:47:42,010 --> 00:47:51,050
OK, here's the plan, let a be
the lowest common ancestor of x

840
00:47:51,050 --> 00:47:52,700
and y.

841
00:47:52,700 --> 00:47:57,110
x is a key, y is a key,
they are nodes in the tree.

842
00:47:57,110 --> 00:47:58,670
This is a changing quantity.

843
00:47:58,670 --> 00:48:01,050
As the tree wiggles
around those rotations,

844
00:48:01,050 --> 00:48:02,830
the least common
ancestor changes.

845
00:48:02,830 --> 00:48:05,911
But at every time,
there is, it has

846
00:48:05,911 --> 00:48:07,160
some of these common ancestor.

847
00:48:07,160 --> 00:48:10,250
Might be x, might be y,
might be some other node.

848
00:48:10,250 --> 00:48:11,840
OK?

849
00:48:11,840 --> 00:48:13,550
I want to look at
a couple of things.

850
00:48:17,460 --> 00:48:34,200
Let's say, right before
x is touched at time i,

851
00:48:34,200 --> 00:48:37,620
or I guess right before time i
would be the proper phrasing.

852
00:48:41,970 --> 00:48:47,250
So we're at this moment, I
want to know does a equal x?

853
00:48:51,730 --> 00:48:58,090
If a does not equal
x, then I'm going

854
00:48:58,090 --> 00:49:02,240
to use the point a comma i.

855
00:49:02,240 --> 00:49:02,800
OK?

856
00:49:02,800 --> 00:49:07,870
Least common ancestor has the
property that x is less than

857
00:49:07,870 --> 00:49:10,420
or equal to a, is less
than or equal to y.

858
00:49:10,420 --> 00:49:12,250
Common ancestor,
least common ancestor

859
00:49:12,250 --> 00:49:15,760
will be between x and y.

860
00:49:15,760 --> 00:49:17,870
And we also know that
it's an ancestor of x,

861
00:49:17,870 --> 00:49:19,030
and it's an ancestor of y.

862
00:49:19,030 --> 00:49:22,550
So, if you're going to
touch x, you must touch a.

863
00:49:22,550 --> 00:49:26,260
If you're going to touch
y, you must touch a.

864
00:49:26,260 --> 00:49:30,520
So a comma i is going to
be some point here, which

865
00:49:30,520 --> 00:49:32,410
is what we need.

866
00:49:32,410 --> 00:49:41,080
Except, if a equals x, sorry,
what the heck did I do?

867
00:49:41,080 --> 00:49:42,070
Transposed again.

868
00:49:42,070 --> 00:49:49,748
OK, this is time i, time
j, x, y, sorry about that.

869
00:49:49,748 --> 00:49:54,550
OK, here's time i, here is a.

870
00:49:54,550 --> 00:49:59,035
So, if a does not equal
x, we know at time i,

871
00:49:59,035 --> 00:50:00,910
we must access
all ancestor of x,

872
00:50:00,910 --> 00:50:04,030
we must touch all ancestors
of x, before we touch x.

873
00:50:04,030 --> 00:50:06,130
Therefore, this is
a point and we're

874
00:50:06,130 --> 00:50:09,295
done, unless a equals
x at this time,

875
00:50:09,295 --> 00:50:10,670
because then it's
the same point.

876
00:50:10,670 --> 00:50:12,336
We didn't get a third
point, we at least

877
00:50:12,336 --> 00:50:15,880
need to find some different
point other than these two.

878
00:50:15,880 --> 00:50:17,620
OK, so that would be good.

879
00:50:17,620 --> 00:50:23,140
We can-- so it must actually be
that at this time, at time i,

880
00:50:23,140 --> 00:50:25,450
a is right here.

881
00:50:25,450 --> 00:50:27,030
Let's then look at time j.

882
00:50:32,110 --> 00:50:36,370
Same deal, at time j,
here's y that gets access.

883
00:50:36,370 --> 00:50:38,620
We must also access a.

884
00:50:38,620 --> 00:50:41,740
Now it could be its equal to y,
or it could be somewhere else.

885
00:50:41,740 --> 00:50:45,250
It could be here, or
could be still here.

886
00:50:45,250 --> 00:50:48,730
In those cases we're
happy, but this one also

887
00:50:48,730 --> 00:50:51,190
could have been at the corner.

888
00:50:51,190 --> 00:50:57,700
The case we're not happy is when
b equals x, sorry, a equals y.

889
00:50:57,700 --> 00:51:00,310
Getting my letters mixed up.

890
00:51:00,310 --> 00:51:02,230
As long as a does
not equal y, then

891
00:51:02,230 --> 00:51:05,512
we can use the point a
comma j, that must be,

892
00:51:05,512 --> 00:51:06,970
these are always
in your execution,

893
00:51:06,970 --> 00:51:10,420
and if a does not equal y, then
we're, that's a third point

894
00:51:10,420 --> 00:51:13,130
and we're done.

895
00:51:13,130 --> 00:51:17,454
So we're left with one more
case, which is that at time i,

896
00:51:17,454 --> 00:51:25,450
a is here, here's a, and
at time j, a is here.

897
00:51:25,450 --> 00:51:28,720
Question is, what
happened in between?

898
00:51:28,720 --> 00:51:29,510
a changed.

899
00:51:32,130 --> 00:51:37,560
For a to change, something
in here has to get rotated.

900
00:51:37,560 --> 00:51:40,950
That's the [? clam. ?] I mean
here's the picture, you have a,

901
00:51:40,950 --> 00:51:46,890
actually-- picture is
at the beginning a is x.

902
00:51:46,890 --> 00:51:51,960
So, here we have x, and then
y is an ancestor, sorry,

903
00:51:51,960 --> 00:51:55,320
y is a descendant of
x, because this is a.

904
00:51:55,320 --> 00:51:57,150
And then somehow we
have to transition

905
00:51:57,150 --> 00:51:59,190
to the reverse picture,
which is that y is

906
00:51:59,190 --> 00:52:03,550
the least common ancestor, x.

907
00:52:03,550 --> 00:52:08,460
And for this to happen, somebody
here has to get rotated.

908
00:52:08,460 --> 00:52:10,500
I guess, in particular x.

909
00:52:10,500 --> 00:52:16,120
At some point x had to
overtake y, had to be moved up.

910
00:52:16,120 --> 00:52:19,170
So, at some point x was
rotated, and that would

911
00:52:19,170 --> 00:52:20,340
correspond to a point here.

912
00:52:23,030 --> 00:52:32,310
So else x must be
rotated at some time

913
00:52:32,310 --> 00:52:37,110
k, where k is between i and j.

914
00:52:47,710 --> 00:52:51,420
And if we set it up right, I
guess because here a was still

915
00:52:51,420 --> 00:53:00,340
x, and here a is y, then it
must be strictly between.

916
00:53:03,700 --> 00:53:06,250
Maybe like this would
be what we want.

917
00:53:09,110 --> 00:53:13,620
And so then we use
the point k comma x.

918
00:53:19,886 --> 00:53:21,050
Is that more or less clear?

919
00:53:24,522 --> 00:53:25,480
This was the easy case.

920
00:53:28,570 --> 00:53:30,790
I guess it depends
what you consider easy.

921
00:53:30,790 --> 00:53:33,980
Here we're just, we're
given a search tree

922
00:53:33,980 --> 00:53:38,810
and the short version is, look
at the least common ancestor.

923
00:53:38,810 --> 00:53:42,460
It's got to move around at
some point, or not, either way

924
00:53:42,460 --> 00:53:44,450
you're happy.

925
00:53:44,450 --> 00:53:46,420
So the least common
ancestor gives you

926
00:53:46,420 --> 00:53:48,650
the points you care about.

927
00:53:48,650 --> 00:53:51,820
So for that we just needed the
least common ancestor idea.

928
00:53:51,820 --> 00:53:53,470
For the other
direction, if we're

929
00:53:53,470 --> 00:53:55,270
given a point set
that corresponds

930
00:53:55,270 --> 00:53:58,510
to, that has this
satisfaction property,

931
00:53:58,510 --> 00:54:02,207
we have to somehow build from
scratch a binary search tree.

932
00:54:02,207 --> 00:54:04,540
How the heck are we going to
build a binary search tree?

933
00:54:04,540 --> 00:54:08,845
Well, with treaps.

934
00:54:37,370 --> 00:54:39,350
So, this is the other direction.

935
00:54:46,520 --> 00:54:52,356
Treap is a portmanteau
of tree and heap.

936
00:54:52,356 --> 00:54:56,180
Underline it
correctly, tree, heap.

937
00:54:56,180 --> 00:55:01,160
So, it's simultaneously a binary
search tree and a min heap,

938
00:55:01,160 --> 00:55:03,110
in this case.

939
00:55:03,110 --> 00:55:05,200
It's a binary search tree
because it has to be.

940
00:55:05,200 --> 00:55:07,790
It's a binary search
tree on the keys.

941
00:55:07,790 --> 00:55:12,170
It's going to be heap on
a different set of values.

942
00:55:12,170 --> 00:55:22,400
So, binary search tree on
the keys, and it's heap

943
00:55:22,400 --> 00:55:32,420
ordered, min heap
ordered, by next access.

944
00:55:35,625 --> 00:55:38,000
I didn't say I was going to
give you an online algorithm,

945
00:55:38,000 --> 00:55:40,280
this is an offline algorithm.

946
00:55:40,280 --> 00:55:44,060
So it looks-- if
I look at a key,

947
00:55:44,060 --> 00:55:48,350
and it's going to be accessed
next, it better be at the root.

948
00:55:48,350 --> 00:55:50,730
Next access will
always be at the root,

949
00:55:50,730 --> 00:55:51,730
if you're heap ordered.

950
00:55:51,730 --> 00:55:54,050
If you're a min
heap by next access.

951
00:55:54,050 --> 00:55:56,150
This is great, that
means the thing you're

952
00:55:56,150 --> 00:55:57,650
searching for is
always at the root,

953
00:55:57,650 --> 00:56:00,860
and it's basically
free to touch.

954
00:56:00,860 --> 00:56:03,295
But you may choose
to touch other nodes.

955
00:56:03,295 --> 00:56:05,870
And in fact, we're told
how to touch notes.

956
00:56:05,870 --> 00:56:07,550
We're given a pattern
that says, well,

957
00:56:07,550 --> 00:56:10,820
at this time you have-- you
will touch this node, this node,

958
00:56:10,820 --> 00:56:12,650
and this node.

959
00:56:12,650 --> 00:56:16,437
By that definition, this
one will be at the root,

960
00:56:16,437 --> 00:56:18,020
but you're going to
touch these nodes,

961
00:56:18,020 --> 00:56:20,750
and possibly you
could rotate them.

962
00:56:20,750 --> 00:56:22,460
Change the tree.

963
00:56:22,460 --> 00:56:24,650
You'll have to, actually,
because next access

964
00:56:24,650 --> 00:56:26,510
time is constantly changing.

965
00:56:26,510 --> 00:56:28,490
And as soon as you
access an item,

966
00:56:28,490 --> 00:56:31,040
it's next access goes in
sometime in the future,

967
00:56:31,040 --> 00:56:34,010
possibly infinity, and so you'd
like to start pushing it down

968
00:56:34,010 --> 00:56:34,510
in the tree.

969
00:56:37,420 --> 00:56:39,420
So, what we need to
do is show that we

970
00:56:39,420 --> 00:56:41,920
can maintain-- it's always going
to be a binary search tree,

971
00:56:41,920 --> 00:56:43,600
because we only do rotations.

972
00:56:43,600 --> 00:56:46,480
We have to somehow use rotations
to maintain this heap order

973
00:56:46,480 --> 00:56:52,240
property, and only touch
the nodes that we're

974
00:56:52,240 --> 00:56:53,920
supposed to touch.

975
00:56:53,920 --> 00:56:57,380
That's the challenge.

976
00:56:57,380 --> 00:57:02,350
So, I should mention, this is
not a uniquely defined tree.

977
00:57:02,350 --> 00:57:05,440
Usually treaps are unique,
if you specify a key order,

978
00:57:05,440 --> 00:57:06,980
and you specify a
heap order, there

979
00:57:06,980 --> 00:57:10,840
is exactly one tree that
satisfies both of them.

980
00:57:10,840 --> 00:57:13,720
But here it's not quite
unique, because the next access

981
00:57:13,720 --> 00:57:17,210
time-- there are many keys that
are going, sorry, next touch.

982
00:57:20,770 --> 00:57:23,020
Next touch time.

983
00:57:23,020 --> 00:57:29,410
So, for example, at this
moment all three of these nodes

984
00:57:29,410 --> 00:57:32,610
are going to be accessed
at the same time.

985
00:57:32,610 --> 00:57:34,975
And so you don't
know, or I'm not

986
00:57:34,975 --> 00:57:37,600
specifying how they're supposed
to be heap ordered in the tree.

987
00:57:37,600 --> 00:57:41,270
Just break ties arbitrarily,
it doesn't matter.

988
00:57:41,270 --> 00:57:43,450
OK.

989
00:57:43,450 --> 00:57:53,800
So, let's look at a time i.

990
00:57:53,800 --> 00:57:57,670
When we reach that
time i, the nodes

991
00:57:57,670 --> 00:58:10,266
to touch form and connected
subtree containing the root.

992
00:58:13,620 --> 00:58:15,820
Because according to
heap order, they're all,

993
00:58:15,820 --> 00:58:17,530
they all want to be at the root.

994
00:58:17,530 --> 00:58:23,440
So we break ties arbitrarily,
somehow, you know all the nodes

995
00:58:23,440 --> 00:58:27,280
that we're supposed to touch,
live in some connected subtree

996
00:58:27,280 --> 00:58:30,300
of the root.

997
00:58:30,300 --> 00:58:34,870
Sorry, some connected
subtree containing the root.

998
00:58:34,870 --> 00:58:40,420
Everything down here has
a later next touch time,

999
00:58:40,420 --> 00:58:45,060
and so they're below, by
definition of heap order.

1000
00:58:45,060 --> 00:58:47,729
OK, now one of these is the
one we actually want to access.

1001
00:58:47,729 --> 00:58:50,020
But we need to touch all of
them, so touch all of them,

1002
00:58:50,020 --> 00:58:50,811
you know, navigate.

1003
00:58:50,811 --> 00:58:52,420
Walk left, right, whatever.

1004
00:58:52,420 --> 00:58:55,360
The big question is, what
should we change this tree into?

1005
00:58:55,360 --> 00:59:01,930
I'd like to change it to
some other top structure.

1006
00:59:01,930 --> 00:59:03,520
I can't touch
anything down here,

1007
00:59:03,520 --> 00:59:05,790
I'm only allowed to
touch these points.

1008
00:59:05,790 --> 00:59:09,507
I only want to
rotate these somehow.

1009
00:59:09,507 --> 00:59:11,590
There's a convenient
theorem, if you have one tree

1010
00:59:11,590 --> 00:59:13,256
and you want to convert
it into another,

1011
00:59:13,256 --> 00:59:15,970
you can always do it in a
linear number of rotations.

1012
00:59:15,970 --> 00:59:18,130
So, rotations are basically
free and this model,

1013
00:59:18,130 --> 00:59:20,650
it's just about how
many nodes we touch.

1014
00:59:20,650 --> 00:59:22,270
We're told which nodes to touch.

1015
00:59:22,270 --> 00:59:25,120
We want to somehow rearrange
them to restore this heap order

1016
00:59:25,120 --> 00:59:26,030
property.

1017
00:59:26,030 --> 00:59:26,530
Right?

1018
00:59:26,530 --> 00:59:28,090
As soon as we touch
all these nodes,

1019
00:59:28,090 --> 00:59:31,810
their next touch time will
be sometime in the future.

1020
00:59:31,810 --> 00:59:34,700
We need to rearrange the
tree to still be heap ordered

1021
00:59:34,700 --> 00:59:37,000
by that new next touch time.

1022
00:59:39,600 --> 00:59:42,250
OK, here's what we do.

1023
00:59:45,731 --> 00:59:47,230
I mean there's only
one thing to do.

1024
00:59:49,870 --> 00:59:54,610
Rearrange those nodes in
this connected subtree

1025
00:59:54,610 --> 01:00:04,240
to be a local treap by
the new next touch time.

1026
01:00:04,240 --> 01:00:11,680
These are the only nodes to
get a new next touch time,

1027
01:00:11,680 --> 01:00:15,970
so it's more or less unique
how to rearrange them.

1028
01:00:15,970 --> 01:00:17,260
Do that.

1029
01:00:17,260 --> 01:00:20,430
Now the hard part is to argue
that the whole thing is now

1030
01:00:20,430 --> 01:00:20,930
a treap.

1031
01:00:24,140 --> 01:00:29,210
Why was it enough to
only modify these nodes?

1032
01:00:29,210 --> 01:00:32,510
Maybe you set one of these nodes
to have a very large next touch

1033
01:00:32,510 --> 01:00:35,199
time, so it's got to be
really deep down there.

1034
01:00:35,199 --> 01:00:37,740
And you can't afford to push it
down deep, because you're not

1035
01:00:37,740 --> 01:00:40,200
allowed to touch
any of these nodes.

1036
01:00:40,200 --> 01:00:44,370
Looks worrisome, but
turns out, it just works.

1037
01:00:47,390 --> 01:00:55,350
So, if there were a failure,
picture would be like this.

1038
01:00:55,350 --> 01:00:59,290
We rearrange these nodes
perfectly, in particular,

1039
01:00:59,290 --> 01:01:01,720
let's look at some
node x that has a child

1040
01:01:01,720 --> 01:01:03,900
y, that was not touched.

1041
01:01:03,900 --> 01:01:06,690
So x was touched, all of
it's ancestors were touched,

1042
01:01:06,690 --> 01:01:09,390
but y was not touched.

1043
01:01:09,390 --> 01:01:12,867
So we know that the
next touch time of x

1044
01:01:12,867 --> 01:01:15,450
is greater than or equal to the
next touch time of its parent,

1045
01:01:15,450 --> 01:01:17,730
of it's ancestor,
up to the root.

1046
01:01:17,730 --> 01:01:20,850
The worry would be that
the next touch time of x

1047
01:01:20,850 --> 01:01:23,720
is greater than the
next touch time of y.

1048
01:01:23,720 --> 01:01:38,802
So suppose next touch of x is
greater than next touch of y.

1049
01:01:38,802 --> 01:01:41,385
This would be a problem, because
then you would not be a heap.

1050
01:01:46,000 --> 01:02:17,850
So, claim is we get an
unsatisfied rectangle

1051
01:02:17,850 --> 01:02:20,940
based on x and it's next touch
time, and y and it's next touch

1052
01:02:20,940 --> 01:02:21,720
time.

1053
01:02:21,720 --> 01:02:24,030
So let's draw the picture.

1054
01:02:24,030 --> 01:02:30,540
Here's time, here's
space, I'm going

1055
01:02:30,540 --> 01:02:34,950
to assume by symmetry x
is to the left of y and

1056
01:02:34,950 --> 01:02:38,970
[? keyspace, ?] and
now we're supposing

1057
01:02:38,970 --> 01:02:42,375
the next touch time of y is
earlier than the next touch

1058
01:02:42,375 --> 01:02:43,050
time of x.

1059
01:02:43,050 --> 01:02:45,820
So it looks like this.

1060
01:02:45,820 --> 01:02:53,730
So this is next touch time of
x, this is the next time of y,

1061
01:02:53,730 --> 01:03:00,041
and I claim that there are
no other points in here.

1062
01:03:00,041 --> 01:03:02,040
That would be a contradiction,
because we assume

1063
01:03:02,040 --> 01:03:03,240
that the thing is satisfied.

1064
01:03:10,650 --> 01:03:16,350
To prove this, I need to go back
a little bit to the definition,

1065
01:03:16,350 --> 01:03:16,890
over here.

1066
01:03:20,955 --> 01:03:22,830
There are actually a
couple of different ways

1067
01:03:22,830 --> 01:03:26,550
to think about satisfaction,
which I was getting at here,

1068
01:03:26,550 --> 01:03:28,140
but I didn't solidify.

1069
01:03:28,140 --> 01:03:29,820
So, I said OK, if
you have two points

1070
01:03:29,820 --> 01:03:31,690
and that rectangle
is satisfied, there

1071
01:03:31,690 --> 01:03:35,980
is some point, possibly in the
interior, in that rectangle.

1072
01:03:35,980 --> 01:03:39,870
But if it's interior,
then I can keep going.

1073
01:03:39,870 --> 01:03:45,840
If I keep going, in the end I
can conclude that not only is

1074
01:03:45,840 --> 01:03:47,730
this rectangle
non-empty, but there

1075
01:03:47,730 --> 01:03:52,880
has to be a point on
one of these two sides,

1076
01:03:52,880 --> 01:03:54,867
because if I choose
any other point,

1077
01:03:54,867 --> 01:03:55,950
I get a smaller rectangle.

1078
01:03:55,950 --> 01:03:58,860
Eventually, I have to get one
on one of those two sides.

1079
01:03:58,860 --> 01:04:01,242
Could be at the
corner, or this corner,

1080
01:04:01,242 --> 01:04:03,450
but one of those two sides
has to have a point on it.

1081
01:04:03,450 --> 01:04:06,789
Also, one of these two sides
has to have a point on it.

1082
01:04:06,789 --> 01:04:08,330
It could be both of
these constraints

1083
01:04:08,330 --> 01:04:12,300
are met at once by having
one point in the corner.

1084
01:04:12,300 --> 01:04:14,760
Well that's a somewhat stronger
formulation, but equivalent

1085
01:04:14,760 --> 01:04:18,120
formulation of the
satisfaction property.

1086
01:04:18,120 --> 01:04:23,160
So in particular over
here, it should be the case

1087
01:04:23,160 --> 01:04:26,100
that there's a point,
either here or here,

1088
01:04:26,100 --> 01:04:28,410
and there should be a
point, either here or here.

1089
01:04:28,410 --> 01:04:30,360
I claim that one of
those is violated.

1090
01:04:45,649 --> 01:04:47,940
You think I'd know this stuff,
I wrote the paper, but--

1091
01:04:50,640 --> 01:04:54,090
it's all these subtle
details, easy to get wrong.

1092
01:04:54,090 --> 01:05:00,040
I think what I want
to look at is, now,

1093
01:05:00,040 --> 01:05:03,580
which is the moment we're
drawing this diagram, versus

1094
01:05:03,580 --> 01:05:06,010
the next time of y.

1095
01:05:06,010 --> 01:05:09,100
Sorry, so this is x comma now.

1096
01:05:11,354 --> 01:05:13,020
That's what my diagram
looks like there,

1097
01:05:13,020 --> 01:05:15,070
so I think that's what I mean.

1098
01:05:15,070 --> 01:05:16,150
So ignore this picture.

1099
01:05:20,190 --> 01:05:23,830
What we learn, what we know
is the next access to x,

1100
01:05:23,830 --> 01:05:25,194
is sometime in the future.

1101
01:05:25,194 --> 01:05:26,360
That's what we're told here.

1102
01:05:26,360 --> 01:05:30,460
Next touch of x is greater
than next touch of y.

1103
01:05:30,460 --> 01:05:35,580
So next touch of x is up here,
which means this is empty.

1104
01:05:35,580 --> 01:05:40,011
OK, if that's empty,
this better not be empty.

1105
01:05:40,011 --> 01:05:42,010
All right that's what we
claim, one of these two

1106
01:05:42,010 --> 01:05:44,830
has to have a point in it.

1107
01:05:44,830 --> 01:05:47,440
This one's empty, so
this better not be empty,

1108
01:05:47,440 --> 01:05:48,670
but I claim this is empty.

1109
01:05:48,670 --> 01:05:53,401
Suppose it's not, suppose it
is, suppose it's not empty--

1110
01:05:53,401 --> 01:05:56,460
Wait, no, one of these.

1111
01:05:56,460 --> 01:06:00,850
Suppose it's not empty, should
be the correct scenario.

1112
01:06:00,850 --> 01:06:03,460
Look at the left most
point in this range.

1113
01:06:09,960 --> 01:06:10,725
This guy.

1114
01:06:15,620 --> 01:06:19,620
It's a point between x and
y, in terms of key value.

1115
01:06:19,620 --> 01:06:23,870
So, in this picture,
where could it be?

1116
01:06:23,870 --> 01:06:29,470
Where are the points between
x and y in this diagram?

1117
01:06:29,470 --> 01:06:31,861
They have to be in
the left subtree of y.

1118
01:06:31,861 --> 01:06:32,360
Right?

1119
01:06:32,360 --> 01:06:34,827
The only points in a binary
search-- if x and y are--

1120
01:06:34,827 --> 01:06:37,160
if y is a child of x, the
only points in the binary tree

1121
01:06:37,160 --> 01:06:40,640
that are between x and y,
or the left subtree of y,

1122
01:06:40,640 --> 01:06:43,400
or there's a symmetric case,
but in this picture left subtree

1123
01:06:43,400 --> 01:06:44,870
of y.

1124
01:06:44,870 --> 01:06:45,970
But I put an x here.

1125
01:06:45,970 --> 01:06:48,500
That means that whoever
we're looking at,

1126
01:06:48,500 --> 01:06:52,760
some point between x and y,
has to be in this top tree.

1127
01:06:52,760 --> 01:06:55,310
Contradiction, done, OK?

1128
01:06:55,310 --> 01:06:58,130
If this guy is in there,
then y was also in there,

1129
01:06:58,130 --> 01:07:01,554
which meant there
was a point here,

1130
01:07:01,554 --> 01:07:03,470
and that's what we're
assuming did not happen.

1131
01:07:03,470 --> 01:07:04,928
This is supposed
to be an interface

1132
01:07:04,928 --> 01:07:07,550
between inside the
set of touched nodes,

1133
01:07:07,550 --> 01:07:10,740
and outside the set
of touched nodes.

1134
01:07:10,740 --> 01:07:14,090
So there can't be
any points in here,

1135
01:07:14,090 --> 01:07:17,686
which means this is empty, which
means you weren't satisfied.

1136
01:07:17,686 --> 01:07:19,310
OK, maybe I should
write down the words

1137
01:07:19,310 --> 01:07:21,110
to go with that argument, but--

1138
01:07:25,680 --> 01:07:34,770
So, this part is empty by
next touch of x being greater

1139
01:07:34,770 --> 01:07:37,530
than next touch of y.

1140
01:07:37,530 --> 01:07:45,180
And this part is empty
else, or it's empty

1141
01:07:45,180 --> 01:08:03,960
because any key
between x and y is

1142
01:08:03,960 --> 01:08:18,189
in the left subtree of
y, which would imply

1143
01:08:18,189 --> 01:08:28,930
if it's touched then so is y.

1144
01:08:28,930 --> 01:08:32,450
But y cannot be
touched, by assumption.

1145
01:08:32,450 --> 01:08:34,960
So that's the end of that proof.

1146
01:08:34,960 --> 01:08:38,137
A little bit longer,
but hopefully

1147
01:08:38,137 --> 01:08:39,470
it's pretty clear at this point.

1148
01:08:39,470 --> 01:08:40,778
Question?

1149
01:08:40,778 --> 01:08:43,148
AUDIENCE: Can't
there be something

1150
01:08:43,148 --> 01:08:45,810
like a descendent of x,
but an ancestor of y,

1151
01:08:45,810 --> 01:08:49,034
instead of being in
a subtree with y?

1152
01:08:49,034 --> 01:08:50,450
PROFESSOR: Would,
so you could say

1153
01:08:50,450 --> 01:08:51,884
it could be in between here.

1154
01:08:51,884 --> 01:08:54,050
It could be a descendant
of x, but an ancestor of y,

1155
01:08:54,050 --> 01:08:56,810
but we're assuming here that
this was a child relation.

1156
01:08:56,810 --> 01:08:58,310
y was a child of x.

1157
01:08:58,310 --> 01:08:59,394
This was a--

1158
01:08:59,394 --> 01:09:01,536
I didn't say that
at the beginning.

1159
01:09:01,536 --> 01:09:03,410
On a claim that's a
global treap, if it's not

1160
01:09:03,410 --> 01:09:06,710
a global treap, there is
some edge that's violated,

1161
01:09:06,710 --> 01:09:08,340
that does not have
heap order property.

1162
01:09:08,340 --> 01:09:11,180
So assuming this was
an edge, x is OK,

1163
01:09:11,180 --> 01:09:13,609
it was in the local
treap, y somehow

1164
01:09:13,609 --> 01:09:16,100
is going to be bad, because
it's next touch time was,

1165
01:09:16,100 --> 01:09:16,970
should be higher.

1166
01:09:16,970 --> 01:09:18,050
Should be above.

1167
01:09:18,050 --> 01:09:19,008
Other question?

1168
01:09:19,008 --> 01:09:21,000
AUDIENCE: So that
[INAUDIBLE] you drew,

1169
01:09:21,000 --> 01:09:25,980
and all the everything in that
subtree root that gets taken

1170
01:09:25,980 --> 01:09:26,976
to--

1171
01:09:26,976 --> 01:09:28,968
Like the picture on
the right is also,

1172
01:09:28,968 --> 01:09:30,462
it's the same subtree right?

1173
01:09:30,462 --> 01:09:32,479
But after you change
their [INAUDIBLE]

1174
01:09:32,479 --> 01:09:34,340
PROFESSOR: These two subtrees
have the same set of nodes,

1175
01:09:34,340 --> 01:09:35,756
they've just been
rotated somehow.

1176
01:09:35,756 --> 01:09:38,926
AUDIENCE: OK, but then
how do you-- but didn't

1177
01:09:38,926 --> 01:09:41,524
we change the next touch times
of all the nodes in there?

1178
01:09:41,524 --> 01:09:43,472
So how you do know if
the root is still going

1179
01:09:43,472 --> 01:09:45,420
to be some guy in that subtree?

1180
01:09:48,850 --> 01:09:50,189
PROFESSOR: Buy this argument.

1181
01:09:50,189 --> 01:09:53,340
So the question is
say, after we do this,

1182
01:09:53,340 --> 01:09:55,860
we make some root,
which is going,

1183
01:09:55,860 --> 01:09:58,110
the root is going to
be among all the nodes

1184
01:09:58,110 --> 01:10:02,280
that just got touched now, who
is going to be touched next?

1185
01:10:02,280 --> 01:10:03,720
That's who we put at the root.

1186
01:10:03,720 --> 01:10:07,050
And the claim is, that
is globally the node that

1187
01:10:07,050 --> 01:10:08,100
will be touched next.

1188
01:10:08,100 --> 01:10:08,800
Why?

1189
01:10:08,800 --> 01:10:11,220
By this argument.

1190
01:10:11,220 --> 01:10:15,360
If there were some other node
down here that has a smaller

1191
01:10:15,360 --> 01:10:18,655
next access time, then--

1192
01:10:22,947 --> 01:10:24,780
but we know that it was
heap ordered before,

1193
01:10:24,780 --> 01:10:26,500
so all of these guys
are heap ordered.

1194
01:10:26,500 --> 01:10:28,680
So, this guy would
then have the minimum.

1195
01:10:28,680 --> 01:10:30,150
And then we look
at that interface,

1196
01:10:30,150 --> 01:10:32,900
and the claim is by the
satisfaction property,

1197
01:10:32,900 --> 01:10:35,306
actually this point should
have been in the set.

1198
01:10:35,306 --> 01:10:36,930
So, what this tells
you is the guy that

1199
01:10:36,930 --> 01:10:38,970
has to be accessed
next, in particular,

1200
01:10:38,970 --> 01:10:41,340
must be in your set.

1201
01:10:41,340 --> 01:10:42,819
Must be touched now.

1202
01:10:46,950 --> 01:10:48,810
Kind of magical.

1203
01:10:48,810 --> 01:10:51,180
Well actually, it's because
they're tie-breaking

1204
01:10:51,180 --> 01:10:53,690
I think, that this works out.

1205
01:10:53,690 --> 01:10:55,454
Anyway, another question?

1206
01:10:55,454 --> 01:10:59,406
AUDIENCE: So, like when you're
rearranging the [INAUDIBLE]

1207
01:10:59,406 --> 01:11:04,800
in the sort of subtree
on top [INAUDIBLE]

1208
01:11:04,800 --> 01:11:06,800
PROFESSOR: Yeah, we're
doing this transformation

1209
01:11:06,800 --> 01:11:09,389
of the top tree into the
local tree by rotations.

1210
01:11:09,389 --> 01:11:09,930
I mentioned--

1211
01:11:09,930 --> 01:11:12,674
AUDIENCE: [INAUDIBLE]
It's always--

1212
01:11:12,674 --> 01:11:14,090
PROFESSOR: Right,
so we're staying

1213
01:11:14,090 --> 01:11:16,548
within the binary search tree
model, and in particular then

1214
01:11:16,548 --> 01:11:18,054
we stay a binary search tree.

1215
01:11:18,054 --> 01:11:19,220
So, we can't mess things up.

1216
01:11:19,220 --> 01:11:21,260
And there's a nice theorem that
if you have two binary search

1217
01:11:21,260 --> 01:11:23,000
trees on the same,
keys there's a way

1218
01:11:23,000 --> 01:11:25,280
to get there with the
linear number of rotates,

1219
01:11:25,280 --> 01:11:28,130
so that's for free.

1220
01:11:28,130 --> 01:11:31,790
So, our new cost model
is just to count points.

1221
01:11:31,790 --> 01:11:34,580
The cost of this access is
one, the cost of this access

1222
01:11:34,580 --> 01:11:37,070
is two, two, three.

1223
01:11:37,070 --> 01:11:40,370
If we just count how
many nodes are touched,

1224
01:11:40,370 --> 01:11:43,550
then the cost of the
binary search tree

1225
01:11:43,550 --> 01:11:48,830
is equal to the cost of
the minimum satisfied

1226
01:11:48,830 --> 01:11:50,270
superset of your point.

1227
01:11:50,270 --> 01:11:52,760
So this is the problem now.

1228
01:11:52,760 --> 01:11:56,390
Sadly we don't know how
to solve the problem.

1229
01:11:56,390 --> 01:12:01,080
We do know some things.

1230
01:12:01,080 --> 01:12:03,822
I don't think I'll go
through an example of this,

1231
01:12:03,822 --> 01:12:04,780
it's not very exciting.

1232
01:12:04,780 --> 01:12:08,180
You could run
through this picture,

1233
01:12:08,180 --> 01:12:10,250
and see how the binary
[? structure ?] changes.

1234
01:12:10,250 --> 01:12:11,708
Actually the binary
[? structure ?]

1235
01:12:11,708 --> 01:12:14,360
won't change it all here, so
it's a little anticlimactic

1236
01:12:14,360 --> 01:12:15,030
of an example.

1237
01:12:15,030 --> 01:12:18,200
You can see it in the notes.

1238
01:12:18,200 --> 01:12:25,540
I want to get to the greedy
algorithm, so let's go here.

1239
01:12:34,850 --> 01:12:35,898
Last bullet.

1240
01:13:14,860 --> 01:13:18,540
The idea is to imagine
your points are added one

1241
01:13:18,540 --> 01:13:20,700
at a time, bottom up.

1242
01:13:24,060 --> 01:13:25,680
So I'm going to do
the same example.

1243
01:13:25,680 --> 01:13:27,780
First we add this point.

1244
01:13:27,780 --> 01:13:29,730
That's a satisfied set, done.

1245
01:13:29,730 --> 01:13:50,230
In general add necessary points
on the same row as the search.

1246
01:13:50,230 --> 01:13:51,760
OK, there's nothing to add here.

1247
01:13:51,760 --> 01:13:53,910
Next point we add is over here.

1248
01:13:53,910 --> 01:13:56,170
I've got the orientation
correct, yeah.

1249
01:13:56,170 --> 01:13:59,060
So this was three, this was one.

1250
01:13:59,060 --> 01:14:00,340
Is this satisfied?

1251
01:14:00,340 --> 01:14:02,937
No, there's a bad
rectangle here.

1252
01:14:02,937 --> 01:14:05,020
There's two obvious ways
to satisfy the rectangle,

1253
01:14:05,020 --> 01:14:07,550
I could add a point here,
or I could add a point here.

1254
01:14:07,550 --> 01:14:09,800
I'm going to add a point
here, because that's the row,

1255
01:14:09,800 --> 01:14:10,720
this is current time.

1256
01:14:10,720 --> 01:14:14,050
OK, it's like a
sweep line algorithm.

1257
01:14:14,050 --> 01:14:18,721
We go up, next
point is over here.

1258
01:14:18,721 --> 01:14:20,890
That's the Next
position to sweep line.

1259
01:14:20,890 --> 01:14:22,840
Now there's a bad rectangle.

1260
01:14:22,840 --> 01:14:24,420
We fix it by adding this point.

1261
01:14:27,010 --> 01:14:29,950
Now we're good, all
rectangles are satisfied.

1262
01:14:29,950 --> 01:14:33,490
Next level is,
there's a point here.

1263
01:14:33,490 --> 01:14:35,440
Now there's two bad rectangles.

1264
01:14:35,440 --> 01:14:38,170
This one, I'm going
to add a point here,

1265
01:14:38,170 --> 01:14:40,976
and this one, I'm going
to add a point here.

1266
01:14:44,640 --> 01:14:46,620
Now we're good.

1267
01:14:46,620 --> 01:14:49,740
And that should be
what I did here.

1268
01:14:49,740 --> 01:14:50,240
Yeah.

1269
01:14:52,619 --> 01:14:54,160
So that's how I
found that point set,

1270
01:14:54,160 --> 01:14:57,540
and in general claim is
this is a good algorithm.

1271
01:14:57,540 --> 01:15:01,320
It seems, in fact,
pretty obvious.

1272
01:15:01,320 --> 01:15:04,260
There was a choice of
course, we could satisfy

1273
01:15:04,260 --> 01:15:05,940
this corner or this corner.

1274
01:15:05,940 --> 01:15:09,330
Or some monotone
path in between.

1275
01:15:09,330 --> 01:15:11,010
But the claim would be that--

1276
01:15:15,510 --> 01:15:17,460
doesn't make that
big a difference.

1277
01:15:17,460 --> 01:15:18,970
Doing things later
is always better.

1278
01:15:18,970 --> 01:15:20,550
It's kind of a lazy property.

1279
01:15:20,550 --> 01:15:22,614
Or you could think of this--

1280
01:15:22,614 --> 01:15:24,030
Originally actually
this algorithm

1281
01:15:24,030 --> 01:15:26,160
goes back in tree land.

1282
01:15:26,160 --> 01:15:29,041
And in tree land, if you follow
through this reduction, which

1283
01:15:29,041 --> 01:15:30,540
we did, you know
if you convert this

1284
01:15:30,540 --> 01:15:33,750
into a treap, what
this is saying is,

1285
01:15:33,750 --> 01:15:36,510
look you search for an
item, you follow a path.

1286
01:15:36,510 --> 01:15:39,150
Take all the nodes on
the path that you follow,

1287
01:15:39,150 --> 01:15:41,700
rearrange them optimally
for the future,

1288
01:15:41,700 --> 01:15:45,690
build a heap based on the next
access time, next touch time,

1289
01:15:45,690 --> 01:15:48,270
whenever that happens to be.

1290
01:15:48,270 --> 01:15:51,060
Next access time
actually, in that case.

1291
01:15:51,060 --> 01:15:55,200
That is equivalent
to this algorithm.

1292
01:15:55,200 --> 01:15:57,457
That seems like the right
thing to do offline.

1293
01:15:57,457 --> 01:16:00,040
You visit your item, you do the
minimum amount you have to do,

1294
01:16:00,040 --> 01:16:01,680
which is following
the search path.

1295
01:16:01,680 --> 01:16:04,590
You rearrange those items to
be optimal for the future.

1296
01:16:04,590 --> 01:16:07,020
It's an offline algorithm,
seems like a really good one.

1297
01:16:07,020 --> 01:16:08,610
The only thing
it's missing out on

1298
01:16:08,610 --> 01:16:10,920
is maybe you should
go off the path

1299
01:16:10,920 --> 01:16:13,962
and bring other guys
closer to the root.

1300
01:16:13,962 --> 01:16:16,170
But if you believe, which
we don't know how to prove,

1301
01:16:16,170 --> 01:16:17,503
if you believe that there's no--

1302
01:16:17,503 --> 01:16:19,140
it doesn't really
buy you anything

1303
01:16:19,140 --> 01:16:22,290
to go off the path now,
you can always do it later,

1304
01:16:22,290 --> 01:16:26,500
then this algorithm
is optimal offline.

1305
01:16:26,500 --> 01:16:28,000
And in terms of the
point set it's--

1306
01:16:28,000 --> 01:16:29,749
in the point set of
view it's kind of nice

1307
01:16:29,749 --> 01:16:31,360
because it almost
looks online, right.

1308
01:16:31,360 --> 01:16:33,510
You only have to
look at each time

1309
01:16:33,510 --> 01:16:37,080
and add the points at
that time that are useful,

1310
01:16:37,080 --> 01:16:38,490
in terms of the past.

1311
01:16:38,490 --> 01:16:41,444
You only had to satisfy
the rectangles of the past.

1312
01:16:41,444 --> 01:16:43,110
So this is where
things get interesting,

1313
01:16:43,110 --> 01:16:46,100
because in terms of a tree
view, with this transformation,

1314
01:16:46,100 --> 01:16:48,810
this looks like an
offline tree because it

1315
01:16:48,810 --> 01:16:49,890
needs to know the future.

1316
01:16:49,890 --> 01:16:52,270
And it does if you
want to build a heap.

1317
01:16:52,270 --> 01:16:54,360
OK, but if you look
at in the geometric

1318
01:16:54,360 --> 01:16:56,640
view, suddenly it looks
online, because you're only

1319
01:16:56,640 --> 01:16:58,306
looking at the points
and all the points

1320
01:16:58,306 --> 01:16:59,940
you've accessed in the past.

1321
01:16:59,940 --> 01:17:04,050
So, in fact, there's a
way to make this online.

1322
01:17:08,550 --> 01:17:11,329
This is where things
get interesting.

1323
01:17:11,329 --> 01:17:12,870
There is a transformation
that if you

1324
01:17:12,870 --> 01:17:17,100
have an online satisfying
point set, meaning you

1325
01:17:17,100 --> 01:17:19,410
can decide what points to
add based only on the past,

1326
01:17:19,410 --> 01:17:21,480
not on the future.

1327
01:17:21,480 --> 01:17:23,770
So it's a fancier version
of this transformation,

1328
01:17:23,770 --> 01:17:27,460
you get an actual online
binary search tree.

1329
01:17:27,460 --> 01:17:33,510
So, this algorithm goes
back to the '90s I think.

1330
01:17:33,510 --> 01:17:37,440
Actually '88, it's in a
thesis 1988 as rediscovered

1331
01:17:37,440 --> 01:17:42,630
by my PhD adviser in 2000.

1332
01:17:42,630 --> 01:17:45,754
It's totally natural
algorithm, but they thought

1333
01:17:45,754 --> 01:17:46,920
it was an offline algorithm.

1334
01:17:46,920 --> 01:17:49,260
With this view, it's
an online algorithm.

1335
01:17:49,260 --> 01:17:51,930
Let me quickly convince
you, or sketch to you,

1336
01:17:51,930 --> 01:17:54,450
how we make this online.

1337
01:17:54,450 --> 01:18:01,647
So we do the same thing, except
we don't know how to heapify,

1338
01:18:01,647 --> 01:18:03,480
because we don't know
the next access times.

1339
01:18:03,480 --> 01:18:05,025
But we know whatever
we touch, it's

1340
01:18:05,025 --> 01:18:06,990
some connected
subtree of the root.

1341
01:18:06,990 --> 01:18:08,040
We know what we touch.

1342
01:18:08,040 --> 01:18:10,230
We touch whatever greedy
tells us to touch.

1343
01:18:10,230 --> 01:18:12,699
We'll touch all
these guys, whatever.

1344
01:18:12,699 --> 01:18:13,740
How do we rearrange them?

1345
01:18:13,740 --> 01:18:15,090
We don't rearrange them.

1346
01:18:15,090 --> 01:18:18,300
We store them into something
called a split tree.

1347
01:18:21,090 --> 01:18:23,340
Split tree has the
feature, it's a tree.

1348
01:18:23,340 --> 01:18:27,930
Binary search tree, and if
you ask for some item x,

1349
01:18:27,930 --> 01:18:31,230
you can move x to the root.

1350
01:18:31,230 --> 01:18:33,750
So then you have a
left subtree of x,

1351
01:18:33,750 --> 01:18:37,410
right subtree of x,
and then delete x,

1352
01:18:37,410 --> 01:18:40,260
and now you're left with
things that are less than x,

1353
01:18:40,260 --> 01:18:42,170
and things that
are greater than x.

1354
01:18:42,170 --> 01:18:44,550
Things are greater than x.

1355
01:18:44,550 --> 01:18:47,280
And you can do all this
in constant amortize time.

1356
01:18:51,030 --> 01:18:53,610
This is what we need,
if you think about here.

1357
01:18:53,610 --> 01:18:56,460
I'm going to take all these
items that were touched,

1358
01:18:56,460 --> 01:18:59,280
throw them into a split tree.

1359
01:18:59,280 --> 01:19:02,430
My resulting structure will
be a tree of split trees.

1360
01:19:02,430 --> 01:19:05,450
So think of it as, when
I touch all these items

1361
01:19:05,450 --> 01:19:07,200
I just sort of throw
them all in the root,

1362
01:19:07,200 --> 01:19:09,540
but that root is
represented by a split tree.

1363
01:19:09,540 --> 01:19:12,180
And then hanging off here, there
are other split trees which

1364
01:19:12,180 --> 01:19:16,290
may have several keys in them.

1365
01:19:16,290 --> 01:19:19,350
When I do, when I
now touch a node,

1366
01:19:19,350 --> 01:19:22,170
you can show that if I'm
trying to touch some node here,

1367
01:19:22,170 --> 01:19:23,880
I can't just magically
touch a node here.

1368
01:19:23,880 --> 01:19:25,670
I've got to, I had
to have followed

1369
01:19:25,670 --> 01:19:28,170
in the actual tree, whatever
the optimal tree is,

1370
01:19:28,170 --> 01:19:30,722
I had to follow some
route to leave path.

1371
01:19:30,722 --> 01:19:32,430
So in fact, the
predecessor and successor

1372
01:19:32,430 --> 01:19:36,390
here had to have been touched
before I touched this one.

1373
01:19:36,390 --> 01:19:40,280
Which means I'm going
to split those nodes.

1374
01:19:40,280 --> 01:19:44,200
So, when I actually-- this
is basically lazy evaluation.

1375
01:19:44,200 --> 01:19:46,780
When I actually access
something in here,

1376
01:19:46,780 --> 01:19:48,550
that means I want to
pull it to the root.

1377
01:19:48,550 --> 01:19:51,520
I wanted to pretend that
it was at the root, that's

1378
01:19:51,520 --> 01:19:53,860
what the treap would have done.

1379
01:19:53,860 --> 01:19:56,620
So basically pull it
up, be a root, split,

1380
01:19:56,620 --> 01:19:59,020
because now there's
two structures left

1381
01:19:59,020 --> 01:20:00,850
where I don't know
their orders, but I

1382
01:20:00,850 --> 01:20:03,880
know that this item was first.

1383
01:20:03,880 --> 01:20:05,269
And so I end up with--

1384
01:20:05,269 --> 01:20:07,060
I don't actually remove
it, but I remove it

1385
01:20:07,060 --> 01:20:11,570
from the split trees, so
I make it look like this.

1386
01:20:11,570 --> 01:20:14,790
And here's the guy where I
wanted to access something.

1387
01:20:14,790 --> 01:20:17,250
So, I split this root
into two split trees,

1388
01:20:17,250 --> 01:20:19,900
and I have an
individual node up here.

1389
01:20:19,900 --> 01:20:21,730
If I can do this in
constant amortize time,

1390
01:20:21,730 --> 01:20:24,140
it's as if this node was at
the root in the first place.

1391
01:20:24,140 --> 01:20:26,970
And so I simulate this
perfect treap order,

1392
01:20:26,970 --> 01:20:29,530
but using a data
structure, split trees,

1393
01:20:29,530 --> 01:20:31,622
which can actually be solved.

1394
01:20:31,622 --> 01:20:32,830
How do you solve split trees?

1395
01:20:32,830 --> 01:20:37,110
You just do the obvious
thing, more or less.

1396
01:20:37,110 --> 01:20:39,610
Ideas, you know red
black trees, take

1397
01:20:39,610 --> 01:20:41,470
your favorite balanced
binary search tree,

1398
01:20:41,470 --> 01:20:45,620
red black trees work fine.

1399
01:20:45,620 --> 01:20:48,160
If you're given a node,
you can split there.

1400
01:20:48,160 --> 01:20:51,670
You basically just
carve it in half.

1401
01:20:51,670 --> 01:20:53,170
How much does it cost to split?

1402
01:20:53,170 --> 01:20:55,210
Well if you're a
little bit clever,

1403
01:20:55,210 --> 01:20:57,887
let me go to a
board of cleverness.

1404
01:21:00,259 --> 01:21:01,800
The one thing we
have to optimize for

1405
01:21:01,800 --> 01:21:03,425
is, what if you're
splitting like right

1406
01:21:03,425 --> 01:21:05,760
here, very close to the left?

1407
01:21:05,760 --> 01:21:08,580
If you're clever,
you'll search from here,

1408
01:21:08,580 --> 01:21:11,040
and cut off this part in
time basically proportional

1409
01:21:11,040 --> 01:21:13,190
to the height of that tree.

1410
01:21:13,190 --> 01:21:15,180
OK, you might get some
propagation up here,

1411
01:21:15,180 --> 01:21:17,722
but that's very small amortized.

1412
01:21:17,722 --> 01:21:19,680
OK, on the other hand,
if you search over here,

1413
01:21:19,680 --> 01:21:22,600
you'd like to spend only
time proportional to this.

1414
01:21:22,600 --> 01:21:27,060
So in general, if you just
search in parallel here,

1415
01:21:27,060 --> 01:21:29,570
you can split in--

1416
01:21:29,570 --> 01:21:34,410
let's say this has size n one,
and the rest has size n two.

1417
01:21:34,410 --> 01:21:41,710
You can split in order log
the min of n one and n two.

1418
01:21:41,710 --> 01:21:44,220
And you can show that if you
just-- that's straightforward

1419
01:21:44,220 --> 01:21:46,210
splitting, that's
really easy to do.

1420
01:21:46,210 --> 01:21:48,930
You can show that that
implies constant amortized,

1421
01:21:48,930 --> 01:21:51,330
because either you're cutting
off a very little nibble

1422
01:21:51,330 --> 01:21:53,310
and the cost is small,
or you're cutting things

1423
01:21:53,310 --> 01:21:55,650
more or less in half, but
that can't happen very much.

1424
01:21:55,650 --> 01:21:59,130
Then you charge to the fact
that log n is going down by one,

1425
01:21:59,130 --> 01:22:03,400
and overall you get a linear
cost to splitting nodes.

1426
01:22:06,070 --> 01:22:07,134
It's an amortization.

1427
01:22:07,134 --> 01:22:09,300
Now the trouble is this is
not a binary search tree.

1428
01:22:09,300 --> 01:22:10,841
How in the heck do
I have to pointers

1429
01:22:10,841 --> 01:22:12,330
that in parallel search?

1430
01:22:12,330 --> 01:22:14,880
Well you have to take these
two halves of the tree

1431
01:22:14,880 --> 01:22:17,310
and interleave them to make
them a binary search tree.

1432
01:22:17,310 --> 01:22:21,210
It's kind of awkward, but just
put it, mash it all together.

1433
01:22:21,210 --> 01:22:24,350
Fold it in half, basically
and turn it upside down,

1434
01:22:24,350 --> 01:22:25,974
and you've got a
binary search tree.

1435
01:22:25,974 --> 01:22:27,390
So there's some
messy stuff there,

1436
01:22:27,390 --> 01:22:29,580
but that's just a
hand-wavy argument

1437
01:22:29,580 --> 01:22:32,400
that you can make greedy online.

1438
01:22:32,400 --> 01:22:35,280
Next class we'll talk about
lower bounds, which almost

1439
01:22:35,280 --> 01:22:36,630
proved the greedy is optimal.

1440
01:22:36,630 --> 01:22:38,630
But not quite.