├── 2014 ├── README.md └── en │ ├── lectures │ ├── week0f.srt │ ├── week0w.srt │ ├── week10m.srt │ ├── week10w.srt │ ├── week12m.srt │ ├── week1m.srt │ ├── week1w.srt │ ├── week2m.srt │ ├── week2w.srt │ ├── week3m.srt │ ├── week3w.srt │ ├── week4m.srt │ ├── week4w.srt │ ├── week5m.srt │ ├── week5w.srt │ ├── week6f.srt │ ├── week7m.srt │ ├── week7w.srt │ ├── week8m.srt │ ├── week8w.srt │ ├── week9m.srt │ └── week9w.srt │ ├── quizzes │ ├── review0.srt │ └── review1.srt │ ├── sections │ ├── less1.srt │ ├── more1.srt │ ├── section10.srt │ ├── section2.srt │ ├── section3.srt │ ├── section4.srt │ ├── section5.srt │ ├── section6.srt │ ├── section7.srt │ ├── section8.srt │ └── section9.srt │ ├── seminars │ ├── 3d_modeling.srt │ ├── android101.srt │ ├── apps_with_objective_c.srt │ ├── aws.srt │ ├── build_tomorrows_library.srt │ ├── cad.srt │ ├── css.srt │ ├── data_analysis_r.srt │ ├── data_visualization.srt │ ├── digital_photography.srt │ ├── glass.srt │ ├── hue_bulbs.srt │ ├── innovative_technologies.srt │ ├── laravel.srt │ ├── meteorjs.srt │ ├── ruby_on_rails.srt │ ├── scale_out_computing.srt │ ├── swift.srt │ └── user_interactions.srt │ └── walkthroughs │ ├── Mashup.srt │ ├── server0.srt │ └── server1.srt ├── 2015 ├── README.md └── en │ ├── lectures │ ├── week0f.srt │ ├── week0w.srt │ ├── week10m.srt │ ├── week10w.srt │ ├── week11f.srt │ ├── week11m.srt │ ├── week12m.srt │ ├── week1f.srt │ ├── week1w.srt │ ├── week2m.srt │ ├── week2w.srt │ ├── week3m.srt │ ├── week3w.srt │ ├── week4m.srt │ ├── week4w.srt │ ├── week5m.srt │ ├── week5w.srt │ ├── week6m.srt │ ├── week7m.srt │ ├── week7w.srt │ ├── week8m.srt │ ├── week8w.srt │ ├── week9m.srt │ └── week9w.srt │ ├── sections │ ├── administrivia.srt │ ├── ajax.srt │ ├── algorithms.srt │ ├── algorithms_summary.srt │ ├── arrays.srt │ ├── binary_search.srt │ ├── bubble_sort.srt │ ├── call_stack.srt │ ├── clas.srt │ ├── command_line.srt │ ├── computational_complexity.srt │ ├── conditional_statements.srt │ ├── css.srt │ ├── custom_types.srt │ ├── data_structures.srt │ ├── data_types.srt │ ├── dll.srt │ ├── dom.srt │ ├── dynamic_memory_allocation.srt │ ├── file_pointers.srt │ ├── functions.srt │ ├── gdb.srt │ ├── gdb_dan_armendariz.srt │ ├── hash_tables.srt │ ├── hexadecimal.srt │ ├── html.srt │ ├── http.srt │ ├── insertion_sort.srt │ ├── internet_primer.srt │ ├── introduction_to_ai.srt │ ├── ip.srt │ ├── javascript.srt │ ├── linear_search.srt │ ├── loops.srt │ ├── magic_numbers.srt │ ├── merge_sort.srt │ ├── mvc.srt │ ├── operators.srt │ ├── php_for_web_development.srt │ ├── php_syntax.srt │ ├── pointers.srt │ ├── queues.srt │ ├── recommender_systems.srt │ ├── recursion.srt │ ├── section1.srt │ ├── section2.srt │ ├── section3.srt │ ├── section4.srt │ ├── section5.srt │ ├── section6.srt │ ├── section7.srt │ ├── section8.srt │ ├── selection_sort.srt │ ├── self_driving_cars.srt │ ├── sll.srt │ ├── sql.srt │ ├── stacks.srt │ ├── structures.srt │ ├── tcp.srt │ ├── tries.srt │ └── variable_scope.srt │ └── seminars │ ├── 2d_games.srt │ ├── aws.srt │ ├── bootstrap.srt │ ├── c_to_python.srt │ ├── docker.srt │ ├── flask.srt │ ├── fun_with_music.srt │ ├── internet_of_things.srt │ ├── objective_c.srt │ ├── programming_with_r.srt │ ├── react.srt │ ├── ruby.srt │ ├── server_01.srt │ ├── server_02.srt │ ├── server_03.srt │ ├── swift.srt │ ├── web_audio.srt │ └── web_scraping.srt ├── 2016 ├── README.md ├── ar │ └── lectures │ │ ├── chapters │ │ ├── README.md │ │ ├── week0Harvard.vtt.docx │ │ ├── week1.vtt.docx │ │ ├── week2.vtt.docx │ │ ├── week3.vtt.docx │ │ ├── week4.vtt.docx │ │ └── week5.vtt.docx │ │ └── subtitles │ │ └── README.md ├── en │ ├── lectures │ │ ├── chapters │ │ │ ├── week0harvard.vtt │ │ │ ├── week0yale.vtt │ │ │ ├── week1.vtt │ │ │ ├── week2.vtt │ │ │ ├── week3.vtt │ │ │ ├── week4.vtt │ │ │ └── week5.vtt │ │ └── subtitles │ │ │ ├── week0harvard.srt │ │ │ ├── week0yale.srt │ │ │ ├── week1.srt │ │ │ ├── week2.srt │ │ │ ├── week3.srt │ │ │ ├── week4.srt │ │ │ └── week5.srt │ └── walkthroughs │ │ ├── caesar.srt │ │ ├── check.srt │ │ ├── credit.srt │ │ ├── fifteen.srt │ │ ├── greedy.srt │ │ ├── hello.srt │ │ ├── initials_less.srt │ │ ├── initials_more.srt │ │ ├── load.srt │ │ ├── mario_less.srt │ │ ├── mario_more.srt │ │ ├── recover.srt │ │ ├── resize_less.srt │ │ ├── resize_more.srt │ │ ├── search.srt │ │ ├── size.srt │ │ ├── sort_less.srt │ │ ├── sort_more.srt │ │ ├── speller.srt │ │ ├── unload.srt │ │ ├── vigenere.srt │ │ ├── water.srt │ │ └── whodunit.srt └── es │ └── lectures │ ├── chapters │ ├── README.md │ ├── week0harvard.vtt │ └── week0yale.vtt │ └── subtitles │ └── README.md ├── .gitignore ├── README.md └── SUMMARY.md /.gitignore: -------------------------------------------------------------------------------- 1 | # Node rules: 2 | ## Grunt intermediate storage (http://gruntjs.com/creating-plugins#storing-task-files) 3 | .grunt 4 | 5 | ## Dependency directory 6 | ## Commenting this out is preferred by some people, see 7 | ## https://docs.npmjs.com/misc/faq#should-i-check-my-node_modules-folder-into-git 8 | node_modules 9 | 10 | # Book build output 11 | _book 12 | 13 | # eBook build output 14 | *.epub 15 | *.mobi 16 | *.pdf 17 | 18 | .DS_Store 19 | -------------------------------------------------------------------------------- /2014/README.md: -------------------------------------------------------------------------------- 1 | # CS50 Translations 2014 2 | 3 | A compilation of CS50's lecture subtitles, lecture notes, problem sets, sections, and walkthroughs, in different languages. 4 | 5 | --- 6 | 7 | ## [English](en/README.md) 8 | 9 | ### Moderator 10 | Colton Ogden 11 | 12 | --- 13 | 14 | ## [Spanish](es/README.md) 15 | 16 | ### Moderator 17 | Walter J. Méndez 18 | 19 | #### Contributors 20 | - Arturo Real 21 | 22 | --- 23 | 24 | ## [Arabic](ar/README.md) 25 | 26 | ### Moderator 27 | Mohamed Ashraf 28 | 29 | #### Contributors 30 | - Kareem Zidane 31 | -------------------------------------------------------------------------------- /2014/en/walkthroughs/server0.srt: -------------------------------------------------------------------------------- 1 | 1 2 | 00:00:00,000 --> 00:00:09,287 3 | 4 | 2 5 | 00:00:09,287 --> 00:00:11,120 6 | DAVID MALAN: So for 7 | this problem set, you're 8 | 9 | 3 10 | 00:00:11,120 --> 00:00:13,236 11 | going to implement your 12 | very own web server. 13 | 14 | 4 15 | 00:00:13,236 --> 00:00:16,110 16 | We've provided you with a bit of 17 | skeleton code that gets you started, 18 | 19 | 5 20 | 00:00:16,110 --> 00:00:17,818 21 | but ultimately, you're 22 | going to finish it 23 | 24 | 6 25 | 00:00:17,818 --> 00:00:19,940 26 | up so that it actually 27 | implements the ability 28 | 29 | 7 30 | 00:00:19,940 --> 00:00:23,980 31 | to serve up web pages, both static 32 | content and also dynamic content, 33 | 34 | 8 35 | 00:00:23,980 --> 00:00:25,090 36 | via PHP. 37 | 38 | 9 39 | 00:00:25,090 --> 00:00:27,380 40 | >> Let's take a look, first by 41 | way of the staff solution, 42 | 43 | 10 44 | 00:00:27,380 --> 00:00:29,390 45 | at what the final result is going to be. 46 | 47 | 11 48 | 00:00:29,390 --> 00:00:33,420 49 | I'm first going to run 50 | tilda cs50/pset6/server 51 | 52 | 12 53 | 00:00:33,420 --> 00:00:36,330 54 | and then dash p to specify 55 | a port and then a number 56 | 57 | 13 58 | 00:00:36,330 --> 00:00:38,410 59 | like 8080, which is pretty common. 60 | 61 | 14 62 | 00:00:38,410 --> 00:00:40,420 63 | And then the name or 64 | the path to directory 65 | 66 | 15 67 | 00:00:40,420 --> 00:00:43,360 68 | that I want to use as the web 69 | server's route, where all of the files 70 | 71 | 16 72 | 00:00:43,360 --> 00:00:44,680 73 | are going to be served up from. 74 | 75 | 17 76 | 00:00:44,680 --> 00:00:46,180 77 | I'm going to go ahead and hit Enter. 78 | 79 | 18 80 | 00:00:46,180 --> 00:00:49,010 81 | And you'll see in color text 82 | here that the web server is 83 | 84 | 19 85 | 00:00:49,010 --> 00:00:52,450 86 | using my public directory and 87 | it's listening on port 8080. 88 | 89 | 20 90 | 00:00:52,450 --> 00:00:55,300 91 | Now let's go over to a web 92 | browser and actually try 93 | 94 | 21 95 | 00:00:55,300 --> 00:00:56,855 96 | to connect to this website. 97 | 98 | 22 99 | 00:00:56,855 --> 00:00:59,230 100 | Notice in the bottom right 101 | hand corner of your appliance, 102 | 103 | 23 104 | 00:00:59,230 --> 00:01:02,040 105 | that there's been all 106 | this time an IP address. 107 | 108 | 24 109 | 00:01:02,040 --> 00:01:03,890 110 | That's a unique identifier 111 | for your computer 112 | 113 | 25 114 | 00:01:03,890 --> 00:01:06,050 115 | that identifies it so 116 | that you can access it 117 | 118 | 26 119 | 00:01:06,050 --> 00:01:08,261 120 | via web browser or any 121 | number of other tools. 122 | 123 | 27 124 | 00:01:08,261 --> 00:01:10,760 125 | So I'm going to go ahead and 126 | open up Chrome in the appliance 127 | 128 | 28 129 | 00:01:10,760 --> 00:01:19,250 130 | and I'm going to visit 131 | http://172.16.254.133 and then 132 | 133 | 29 134 | 00:01:19,250 --> 00:01:20,960 135 | colon 8080. 136 | 137 | 30 138 | 00:01:20,960 --> 00:01:24,344 139 | And the colon's important because if 140 | you don't specify that port that I also 141 | 142 | 31 143 | 00:01:24,344 --> 00:01:26,260 144 | specified at the command 145 | line, you're actually 146 | 147 | 32 148 | 00:01:26,260 --> 00:01:28,390 149 | going to be talking into 150 | the appliance's own web 151 | 152 | 33 153 | 00:01:28,390 --> 00:01:30,850 154 | server called Apache, 155 | which is built into it. 156 | 157 | 34 158 | 00:01:30,850 --> 00:01:33,610 159 | But today we want to focus 160 | on our own web server. 161 | 162 | 35 163 | 00:01:33,610 --> 00:01:36,550 164 | >> So now when I hit Enter, 165 | you'll notice that 501 166 | 167 | 36 168 | 00:01:36,550 --> 00:01:38,380 169 | Not Implemented comes 170 | up because I've tried 171 | 172 | 37 173 | 00:01:38,380 --> 00:01:41,000 174 | to access a directory, 175 | not a particular file. 176 | 177 | 38 178 | 00:01:41,000 --> 00:01:43,980 179 | Indeed, if you look over to 180 | the left in my terminal window, 181 | 182 | 39 183 | 00:01:43,980 --> 00:01:46,690 184 | you'll see that while 185 | listening on port 8080, 186 | 187 | 40 188 | 00:01:46,690 --> 00:01:52,600 189 | the web server saw a request for 190 | GET/HTTP/1.1 and then the web server 191 | 192 | 41 193 | 00:01:52,600 --> 00:01:56,680 194 | responded, as pictured here in 195 | red, with that 501 Not Implemented. 196 | 197 | 42 198 | 00:01:56,680 --> 00:01:59,270 199 | >> Curiously though, there's also 200 | this second line in white, 201 | 202 | 43 203 | 00:01:59,270 --> 00:02:03,355 204 | GET/favicon.ico HTTP/1.1. 205 | 206 | 44 207 | 00:02:03,355 --> 00:02:06,230 208 | Now I definitely didn't do that 209 | myself, but it turns out that Chrome, 210 | 211 | 45 212 | 00:02:06,230 --> 00:02:09,910 213 | like a lot of browsers, will 214 | presumptuously assume that your website 215 | 216 | 46 217 | 00:02:09,910 --> 00:02:13,170 218 | is supposed to have a little 219 | graphical icon up in the tab or next 220 | 221 | 47 222 | 00:02:13,170 --> 00:02:16,380 223 | to the address bar, like a Harvard 224 | crest or something along those lines, 225 | 226 | 48 227 | 00:02:16,380 --> 00:02:19,425 228 | and so it's just guessing by 229 | way of this default file name, 230 | 231 | 49 232 | 00:02:19,425 --> 00:02:21,800 233 | that you might have a file 234 | like that too, which we don't. 235 | 236 | 50 237 | 00:02:21,800 --> 00:02:24,650 238 | And so 404 Not Found gets spit back. 239 | 240 | 51 241 | 00:02:24,650 --> 00:02:26,120 242 | >> Well now, notice this. 243 | 244 | 52 245 | 00:02:26,120 --> 00:02:29,440 246 | In addition to visiting 247 | this address inside 248 | 249 | 53 250 | 00:02:29,440 --> 00:02:34,940 251 | of the appliance, 172.16.254.133:8080, 252 | but your IP address, to be clear, 253 | 254 | 54 255 | 00:02:34,940 --> 00:02:35,910 256 | will be different. 257 | 258 | 55 259 | 00:02:35,910 --> 00:02:39,690 260 | Notice that if I go on my Mac 261 | or my PC to my own browser 262 | 263 | 56 264 | 00:02:39,690 --> 00:02:43,200 265 | and visit that same URL, I can 266 | see from my own preferred browser 267 | 268 | 57 269 | 00:02:43,200 --> 00:02:46,340 270 | whether it's Chrome or Firefox 271 | or IE or something else, exactly 272 | 273 | 58 274 | 00:02:46,340 --> 00:02:47,550 275 | the same results. 276 | 277 | 59 278 | 00:02:47,550 --> 00:02:48,130 279 | >> OK. 280 | 281 | 60 282 | 00:02:48,130 --> 00:02:51,820 283 | Let's actually visit a URL that's known 284 | to exist in that public directory. 285 | 286 | 61 287 | 00:02:51,820 --> 00:02:56,890 288 | Namely, the IP address 289 | colon 8080/cat.jpg. 290 | 291 | 62 292 | 00:02:56,890 --> 00:02:57,930 293 | Enter. 294 | 295 | 63 296 | 00:02:57,930 --> 00:02:59,470 297 | And there, indeed, is Happy Cat. 298 | 299 | 64 300 | 00:02:59,470 --> 00:03:03,340 301 | I know in advance that there's also 302 | a cat.HTLM file, so if I hit Enter, 303 | 304 | 65 305 | 00:03:03,340 --> 00:03:04,469 306 | I see that one as well. 307 | 308 | 66 309 | 00:03:04,469 --> 00:03:06,260 310 | And notice, in the 311 | meantime, on the left we 312 | 313 | 67 314 | 00:03:06,260 --> 00:03:08,176 315 | have a whole bunch of 316 | green outputs signifying 317 | 318 | 68 319 | 00:03:08,176 --> 00:03:13,360 320 | that these were 200 statuses, 321 | which means they were OK. 322 | 323 | 69 324 | 00:03:13,360 --> 00:03:18,294 325 | -------------------------------------------------------------------------------- /2015/README.md: -------------------------------------------------------------------------------- 1 | # CS50 Translations 2015 2 | 3 | A compilation of CS50's lecture subtitles, lecture notes, problem sets, sections, and walkthroughs, in different languages. 4 | 5 | --- 6 | 7 | ## [English](en/README.md) 8 | 9 | ### Moderator 10 | Colton Ogden 11 | 12 | --- 13 | 14 | ## [Spanish](es/README.md) 15 | 16 | ### Moderator 17 | Walter J. Méndez 18 | 19 | #### Contributors 20 | - Arturo Real 21 | 22 | --- 23 | 24 | ## [Arabic](ar/README.md) 25 | 26 | ### Moderator 27 | Mohamed Ashraf 28 | 29 | #### Contributors 30 | - Kareem Zidane 31 | -------------------------------------------------------------------------------- /2015/en/sections/algorithms.srt: -------------------------------------------------------------------------------- 1 | 1 2 | 00:00:00,000 --> 00:00:05,710 3 | 4 | 2 5 | 00:00:05,710 --> 00:00:08,900 6 | >> DOUG LLOYD: So in CS50 we learn about 7 | a variety of sorting and searching 8 | 9 | 3 10 | 00:00:08,900 --> 00:00:09,432 11 | algorithms. 12 | 13 | 4 14 | 00:00:09,432 --> 00:00:11,390 15 | And sometimes it can be 16 | a little tricky to keep 17 | 18 | 5 19 | 00:00:11,390 --> 00:00:14,369 20 | track of what algorithm does what. 21 | 22 | 6 23 | 00:00:14,369 --> 00:00:15,910 24 | We really only skim the surface, too. 25 | 26 | 7 27 | 00:00:15,910 --> 00:00:18,700 28 | There are many other searching 29 | and sorting algorithms. 30 | 31 | 8 32 | 00:00:18,700 --> 00:00:21,770 33 | So in this video, let's 34 | just take a few minutes 35 | 36 | 9 37 | 00:00:21,770 --> 00:00:24,940 38 | to try and distill each algorithm 39 | down to its core elements 40 | 41 | 10 42 | 00:00:24,940 --> 00:00:27,790 43 | so you can remember the most 44 | important information about them, 45 | 46 | 11 47 | 00:00:27,790 --> 00:00:31,910 48 | and be able to articulate the 49 | differences, if necessary. 50 | 51 | 12 52 | 00:00:31,910 --> 00:00:34,190 53 | >> The first is selection sort. 54 | 55 | 13 56 | 00:00:34,190 --> 00:00:38,190 57 | The basic idea behind selection sort 58 | is find the smallest unsorted element 59 | 60 | 14 61 | 00:00:38,190 --> 00:00:42,820 62 | in an array, and swap it with the 63 | first unsorted element of that array. 64 | 65 | 15 66 | 00:00:42,820 --> 00:00:46,800 67 | We said that the worst case 68 | runtime of that was n squared. 69 | 70 | 16 71 | 00:00:46,800 --> 00:00:50,040 72 | And if you want to recall why, take 73 | a look at the selection sort video. 74 | 75 | 17 76 | 00:00:50,040 --> 00:00:54,420 77 | The best case runtime is also n squared. 78 | 79 | 18 80 | 00:00:54,420 --> 00:00:58,880 81 | >> Bubble sort, the idea behind that 82 | one, is to swap adjacent pairs. 83 | 84 | 19 85 | 00:00:58,880 --> 00:01:01,700 86 | So that's the keyword that helps 87 | you remember the difference here. 88 | 89 | 20 90 | 00:01:01,700 --> 00:01:04,610 91 | Selection sort, is so 92 | far find the smallest, 93 | 94 | 21 95 | 00:01:04,610 --> 00:01:06,790 96 | bubble sort is swap adjacent pairs. 97 | 98 | 22 99 | 00:01:06,790 --> 00:01:09,750 100 | We swap adjacent pairs of 101 | elements if they are out of order. 102 | 103 | 23 104 | 00:01:09,750 --> 00:01:12,860 105 | Which effectively bubbles 106 | larger elements to the right, 107 | 108 | 24 109 | 00:01:12,860 --> 00:01:17,000 110 | and at the same time, it also begins 111 | to move smaller elements to the left. 112 | 113 | 25 114 | 00:01:17,000 --> 00:01:20,150 115 | >> The worst case runtime of 116 | bubble sort is n squared. 117 | 118 | 26 119 | 00:01:20,150 --> 00:01:23,486 120 | The best case runtime 121 | of bubble sort is n. 122 | 123 | 27 124 | 00:01:23,486 --> 00:01:25,360 125 | Because in that situation 126 | we don't actually-- 127 | 128 | 28 129 | 00:01:25,360 --> 00:01:27,151 130 | we might not need to 131 | make any swaps at all. 132 | 133 | 29 134 | 00:01:27,151 --> 00:01:31,410 135 | We only have to make one 136 | pass across all elements. 137 | 138 | 30 139 | 00:01:31,410 --> 00:01:34,590 140 | >> In insertion sort, the 141 | basic idea here is shifting. 142 | 143 | 31 144 | 00:01:34,590 --> 00:01:36,550 145 | That's the keyword for insertion sort. 146 | 147 | 32 148 | 00:01:36,550 --> 00:01:39,590 149 | We're going to step once through 150 | the array from left to right. 151 | 152 | 33 153 | 00:01:39,590 --> 00:01:41,660 154 | And as we do, we're 155 | going to shift elements 156 | 157 | 34 158 | 00:01:41,660 --> 00:01:46,250 159 | we've already seen to make room for 160 | smaller ones that need to fit somewhere 161 | 162 | 35 163 | 00:01:46,250 --> 00:01:48,060 164 | back in that sorted portion. 165 | 166 | 36 167 | 00:01:48,060 --> 00:01:51,630 168 | >> So we build the sorted array one 169 | element at a time, left to right. 170 | 171 | 37 172 | 00:01:51,630 --> 00:01:54,670 173 | And we shift things to make room. 174 | 175 | 38 176 | 00:01:54,670 --> 00:01:58,600 177 | The worst case runtime of 178 | insertion sort is n squared. 179 | 180 | 39 181 | 00:01:58,600 --> 00:02:02,360 182 | The best case runtime is n. 183 | 184 | 40 185 | 00:02:02,360 --> 00:02:05,370 186 | >> Merge sort, the keyword 187 | here is split and merge. 188 | 189 | 41 190 | 00:02:05,370 --> 00:02:08,930 191 | We split the full array-- whether 192 | it's six elements, eight elements, 193 | 194 | 42 195 | 00:02:08,930 --> 00:02:13,780 196 | 10,000 elements-- we split it 197 | down by half, by half, by half, 198 | 199 | 43 200 | 00:02:13,780 --> 00:02:19,380 201 | until we have an array of n one-element 202 | arrays-- a set of n one-element arrays. 203 | 204 | 44 205 | 00:02:19,380 --> 00:02:22,710 206 | So we started with one a 207 | thousand-elementary array, 208 | 209 | 45 210 | 00:02:22,710 --> 00:02:26,550 211 | and we get to the point where we 212 | have 1,000 one-element arrays. 213 | 214 | 46 215 | 00:02:26,550 --> 00:02:30,960 216 | >> Then we begin to merge those sub arrays 217 | back together in the correct order. 218 | 219 | 47 220 | 00:02:30,960 --> 00:02:34,800 221 | So we take two one-element arrays, 222 | and create a two-element array. 223 | 224 | 48 225 | 00:02:34,800 --> 00:02:38,130 226 | We take two two-element arrays, 227 | and create a four-element array. 228 | 229 | 49 230 | 00:02:38,130 --> 00:02:43,860 231 | And so on and so on, until we've 232 | again rebuilt one n-element array. 233 | 234 | 50 235 | 00:02:43,860 --> 00:02:48,340 236 | >> The worst case runtime of 237 | merge sort is n times log n. 238 | 239 | 51 240 | 00:02:48,340 --> 00:02:52,380 241 | We have n elements, but 242 | this recombining process 243 | 244 | 52 245 | 00:02:52,380 --> 00:02:56,910 246 | takes log n steps to get 247 | back to a full array. 248 | 249 | 53 250 | 00:02:56,910 --> 00:03:01,110 251 | The best case runtime is also n log 252 | n because this process doesn't really 253 | 254 | 54 255 | 00:03:01,110 --> 00:03:05,450 256 | care whether the array was sorted or not 257 | to start with, the process is the same. 258 | 259 | 55 260 | 00:03:05,450 --> 00:03:07,550 261 | There's no way to short circuit things. 262 | 263 | 56 264 | 00:03:07,550 --> 00:03:11,530 265 | So n log n in the worst case, 266 | n log n in the best case. 267 | 268 | 57 269 | 00:03:11,530 --> 00:03:13,920 270 | >> We also talked about two 271 | searching algorithms. 272 | 273 | 58 274 | 00:03:13,920 --> 00:03:16,150 275 | So linear search is about iterating. 276 | 277 | 59 278 | 00:03:16,150 --> 00:03:19,480 279 | We proceed across the array 280 | once, from left to right, 281 | 282 | 60 283 | 00:03:19,480 --> 00:03:21,890 284 | trying to find the number 285 | that we're looking for. 286 | 287 | 61 288 | 00:03:21,890 --> 00:03:24,490 289 | >> The worst case runtime is big O of n. 290 | 291 | 62 292 | 00:03:24,490 --> 00:03:27,550 293 | It might take us to iterating 294 | across every single element 295 | 296 | 63 297 | 00:03:27,550 --> 00:03:30,580 298 | to find the element we're looking 299 | for, either in the last position, 300 | 301 | 64 302 | 00:03:30,580 --> 00:03:31,900 303 | or not at all. 304 | 305 | 65 306 | 00:03:31,900 --> 00:03:34,690 307 | But we can't confirm that until 308 | we've looked at everything. 309 | 310 | 66 311 | 00:03:34,690 --> 00:03:36,680 312 | In the best case, we find immediately. 313 | 314 | 67 315 | 00:03:36,680 --> 00:03:41,030 316 | The best case runtime of 317 | linear search is omega of one. 318 | 319 | 68 320 | 00:03:41,030 --> 00:03:43,964 321 | >> Lastly, there was binary search, 322 | which requires a sorted array. 323 | 324 | 69 325 | 00:03:43,964 --> 00:03:45,880 326 | Remember that's a very 327 | important consideration 328 | 329 | 70 330 | 00:03:45,880 --> 00:03:47,360 331 | when working with binary search. 332 | 333 | 71 334 | 00:03:47,360 --> 00:03:48,770 335 | It's a prerequisite to using it. 336 | 337 | 72 338 | 00:03:48,770 --> 00:03:52,110 339 | The array that you're looking 340 | through must be sorted. 341 | 342 | 73 343 | 00:03:52,110 --> 00:03:54,460 344 | Otherwise, the keyword 345 | is divide and conquer. 346 | 347 | 74 348 | 00:03:54,460 --> 00:03:58,300 349 | Split the array into half, and 350 | eliminate half of the elements 351 | 352 | 75 353 | 00:03:58,300 --> 00:04:00,790 354 | every time, as you proceed through. 355 | 356 | 76 357 | 00:04:00,790 --> 00:04:04,270 358 | >> Because of this divide and conquer 359 | and splitting things in half approach, 360 | 361 | 77 362 | 00:04:04,270 --> 00:04:07,400 363 | the worst case runtime 364 | of binary search is 365 | 366 | 78 367 | 00:04:07,400 --> 00:04:11,690 368 | log n, which is substantially 369 | better than linear searches n. 370 | 371 | 79 372 | 00:04:11,690 --> 00:04:13,590 373 | The best case runtime is still one. 374 | 375 | 80 376 | 00:04:13,590 --> 00:04:16,750 377 | You might find it immediately the 378 | first time we make a division. 379 | 380 | 81 381 | 00:04:16,750 --> 00:04:19,950 382 | But again, remember, that although 383 | binary search is substantially 384 | 385 | 82 386 | 00:04:19,950 --> 00:04:24,000 387 | better than linear search, by 388 | virtue of being log n vs n, 389 | 390 | 83 391 | 00:04:24,000 --> 00:04:26,830 392 | you might have to go through the 393 | work of sorting your array first, 394 | 395 | 84 396 | 00:04:26,830 --> 00:04:29,190 397 | which might make it less 398 | effective, depending 399 | 400 | 85 401 | 00:04:29,190 --> 00:04:32,000 402 | on the size of the array being sorted. 403 | 404 | 86 405 | 00:04:32,000 --> 00:04:32,970 406 | >> I'm Doug Lloyd. 407 | 408 | 87 409 | 00:04:32,970 --> 00:04:34,930 410 | This is CS50. 411 | 412 | 88 413 | 00:04:34,930 --> 00:04:36,757 414 | -------------------------------------------------------------------------------- /2015/en/sections/algorithms_summary.srt: -------------------------------------------------------------------------------- 1 | 1 2 | 00:00:00,000 --> 00:00:05,760 3 | 4 | 2 5 | 00:00:05,760 --> 00:00:08,900 6 | >> DOUG LLOYD: So in CS50 we learned about 7 | a variety of sorting and searching 8 | 9 | 3 10 | 00:00:08,900 --> 00:00:09,442 11 | algorithms. 12 | 13 | 4 14 | 00:00:09,442 --> 00:00:11,400 15 | And sometimes it can be 16 | a little tricky to keep 17 | 18 | 5 19 | 00:00:11,400 --> 00:00:14,161 20 | track of what algorithm does what. 21 | 22 | 6 23 | 00:00:14,161 --> 00:00:15,910 24 | We've really only 25 | skimmed the surface too, 26 | 27 | 7 28 | 00:00:15,910 --> 00:00:18,740 29 | there are many other searching 30 | and sorting algorithms. 31 | 32 | 8 33 | 00:00:18,740 --> 00:00:21,780 34 | So in this video let's 35 | just take a few minutes 36 | 37 | 9 38 | 00:00:21,780 --> 00:00:24,980 39 | to try and distill each algorithm 40 | down to its core elements 41 | 42 | 10 43 | 00:00:24,980 --> 00:00:27,810 44 | so you can remember the most 45 | important information about them 46 | 47 | 11 48 | 00:00:27,810 --> 00:00:31,970 49 | and be able to articulate the 50 | differences, if necessary. 51 | 52 | 12 53 | 00:00:31,970 --> 00:00:34,220 54 | >> The first is selection sort. 55 | 56 | 13 57 | 00:00:34,220 --> 00:00:38,210 58 | The basic idea behind selection sort 59 | is find the smallest unsorted element 60 | 61 | 14 62 | 00:00:38,210 --> 00:00:42,890 63 | in an array and swap it with the 64 | first unsorted element of that array. 65 | 66 | 15 67 | 00:00:42,890 --> 00:00:46,620 68 | We said that the worst-case 69 | run time of that was n squared. 70 | 71 | 16 72 | 00:00:46,620 --> 00:00:50,060 73 | And if you want to recall why, take 74 | a look at the selection sort video. 75 | 76 | 17 77 | 00:00:50,060 --> 00:00:54,560 78 | The best-case run time 79 | is also n squared. 80 | 81 | 18 82 | 00:00:54,560 --> 00:00:58,910 83 | >> Bubble sort, the idea behind that 84 | one is to swap adjacent pairs. 85 | 86 | 19 87 | 00:00:58,910 --> 00:01:01,730 88 | So that's the key that helps you 89 | remember the difference here. 90 | 91 | 20 92 | 00:01:01,730 --> 00:01:04,920 93 | Selection sort is, so far, 94 | find the smallest-- bubble 95 | 96 | 21 97 | 00:01:04,920 --> 00:01:06,790 98 | sort is swap adjacent pairs. 99 | 100 | 22 101 | 00:01:06,790 --> 00:01:08,710 102 | We swap adjacent pairs 103 | of elements if they 104 | 105 | 23 106 | 00:01:08,710 --> 00:01:12,530 107 | are out of order, which effectively 108 | bubbles larger elements to the right, 109 | 110 | 24 111 | 00:01:12,530 --> 00:01:17,060 112 | and at the same time it also begins 113 | to move smaller elements to the left. 114 | 115 | 25 116 | 00:01:17,060 --> 00:01:20,180 117 | The worst-case case run time 118 | of bubble sort is n squared. 119 | 120 | 26 121 | 00:01:20,180 --> 00:01:23,476 122 | The best-case run time 123 | of bubble sort is n. 124 | 125 | 27 126 | 00:01:23,476 --> 00:01:25,350 127 | Because in that situation 128 | we don't actually-- 129 | 130 | 28 131 | 00:01:25,350 --> 00:01:27,141 132 | we might not need to 133 | make any swaps at all. 134 | 135 | 29 136 | 00:01:27,141 --> 00:01:31,026 137 | We only have to make one 138 | pass across all n elements. 139 | 140 | 30 141 | 00:01:31,026 --> 00:01:34,600 142 | >> In insertion sort, the 143 | basic idea here is shifting. 144 | 145 | 31 146 | 00:01:34,600 --> 00:01:36,630 147 | That's the keyword for insertion sort. 148 | 149 | 32 150 | 00:01:36,630 --> 00:01:39,630 151 | We're going to step once through 152 | the array from left to right. 153 | 154 | 33 155 | 00:01:39,630 --> 00:01:41,670 156 | And as we do, we're 157 | going to shift elements 158 | 159 | 34 160 | 00:01:41,670 --> 00:01:46,260 161 | we've already seen to make room for 162 | smaller ones that need to fit somewhere 163 | 164 | 35 165 | 00:01:46,260 --> 00:01:48,080 166 | back in that sorted portion. 167 | 168 | 36 169 | 00:01:48,080 --> 00:01:51,600 170 | So we build the sorted array one 171 | element at a time, left to right, 172 | 173 | 37 174 | 00:01:51,600 --> 00:01:54,740 175 | and we shift things to make room. 176 | 177 | 38 178 | 00:01:54,740 --> 00:01:58,650 179 | The worst-case run time of 180 | insertion sort is n squared. 181 | 182 | 39 183 | 00:01:58,650 --> 00:02:02,380 184 | The best-case run time is n. 185 | 186 | 40 187 | 00:02:02,380 --> 00:02:05,380 188 | >> Merge sort-- the keyword 189 | here is split and merge. 190 | 191 | 41 192 | 00:02:05,380 --> 00:02:08,949 193 | We split the full array, whether 194 | it's six elements, eight elements, 195 | 196 | 42 197 | 00:02:08,949 --> 00:02:13,790 198 | 10,000 elements-- we split it 199 | down by half, by half, by half, 200 | 201 | 43 202 | 00:02:13,790 --> 00:02:17,720 203 | until we have under array 204 | of n one element arrays. 205 | 206 | 44 207 | 00:02:17,720 --> 00:02:19,470 208 | A set of n one element arrays. 209 | 210 | 45 211 | 00:02:19,470 --> 00:02:22,640 212 | So we started with one 213 | 1,000-element array, 214 | 215 | 46 216 | 00:02:22,640 --> 00:02:26,550 217 | and we get to the point where we 218 | have 1,000 one-element arrays. 219 | 220 | 47 221 | 00:02:26,550 --> 00:02:30,990 222 | Then we begin to merge those sub arrays 223 | back together in the correct order. 224 | 225 | 48 226 | 00:02:30,990 --> 00:02:34,860 227 | So we take two one-element arrays 228 | and create a two-element array. 229 | 230 | 49 231 | 00:02:34,860 --> 00:02:38,180 232 | We take two two-element arrays 233 | and create a four-element array 234 | 235 | 50 236 | 00:02:38,180 --> 00:02:43,900 237 | and so on and so on until we've 238 | again rebuilt one n element array. 239 | 240 | 51 241 | 00:02:43,900 --> 00:02:48,410 242 | >> The worst-case run time of 243 | merge sort is n times log n. 244 | 245 | 52 246 | 00:02:48,410 --> 00:02:52,390 247 | We have n elements, but 248 | this recombining process 249 | 250 | 53 251 | 00:02:52,390 --> 00:02:56,960 252 | takes log n steps to get 253 | back to a full array. 254 | 255 | 54 256 | 00:02:56,960 --> 00:03:01,160 257 | The best case run time is also n log 258 | n because this process doesn't really 259 | 260 | 55 261 | 00:03:01,160 --> 00:03:04,090 262 | care whether the array was 263 | sorted or not to start with. 264 | 265 | 56 266 | 00:03:04,090 --> 00:03:07,590 267 | The process is the same, there's 268 | no way to short circuit things. 269 | 270 | 57 271 | 00:03:07,590 --> 00:03:11,610 272 | So n log n in the worst case, 273 | n log n in the best case. 274 | 275 | 58 276 | 00:03:11,610 --> 00:03:13,960 277 | >> We talked about two 278 | searching algorithms. 279 | 280 | 59 281 | 00:03:13,960 --> 00:03:16,230 282 | So linear search is about iterating. 283 | 284 | 60 285 | 00:03:16,230 --> 00:03:19,500 286 | We proceed across the array 287 | once, from left to right, 288 | 289 | 61 290 | 00:03:19,500 --> 00:03:21,950 291 | trying to find the number 292 | that we're looking for. 293 | 294 | 62 295 | 00:03:21,950 --> 00:03:24,550 296 | The worst-case run time is big O of n. 297 | 298 | 63 299 | 00:03:24,550 --> 00:03:27,610 300 | It might take us iterating 301 | across every single element 302 | 303 | 64 304 | 00:03:27,610 --> 00:03:30,660 305 | to find the element we're looking 306 | for, either in the last position, 307 | 308 | 65 309 | 00:03:30,660 --> 00:03:31,630 310 | or not at all. 311 | 312 | 66 313 | 00:03:31,630 --> 00:03:34,720 314 | But we can't confirm that until 315 | we've looked at everything. 316 | 317 | 67 318 | 00:03:34,720 --> 00:03:36,730 319 | m the best-case, we find immediately. 320 | 321 | 68 322 | 00:03:36,730 --> 00:03:41,060 323 | The best-case run time of 324 | linear search is omega of 1. 325 | 326 | 69 327 | 00:03:41,060 --> 00:03:43,689 328 | >> Lastly, there was binary search, 329 | which requires assorted array. 330 | 331 | 70 332 | 00:03:43,689 --> 00:03:45,605 333 | Remember that's a very 334 | important consideration 335 | 336 | 71 337 | 00:03:45,605 --> 00:03:47,155 338 | when working with binary search. 339 | 340 | 72 341 | 00:03:47,155 --> 00:03:50,180 342 | It's a prerequisite to using it-- 343 | the array that you're looking through 344 | 345 | 73 346 | 00:03:50,180 --> 00:03:52,160 347 | must be sorted. 348 | 349 | 74 350 | 00:03:52,160 --> 00:03:54,500 351 | Otherwise, the keyword 352 | is divide and conquer. 353 | 354 | 75 355 | 00:03:54,500 --> 00:03:58,310 356 | Split the array into half and 357 | eliminate half of the elements 358 | 359 | 76 360 | 00:03:58,310 --> 00:04:00,780 361 | every time as you proceed through. 362 | 363 | 77 364 | 00:04:00,780 --> 00:04:04,330 365 | Because of this divide and conquer 366 | and splitting things in half approach, 367 | 368 | 78 369 | 00:04:04,330 --> 00:04:07,450 370 | the worst-case run time 371 | of binary search is 372 | 373 | 79 374 | 00:04:07,450 --> 00:04:11,730 375 | log n, which is substantially 376 | better than linear search's n. 377 | 378 | 80 379 | 00:04:11,730 --> 00:04:13,570 380 | The best-case run time is still one. 381 | 382 | 81 383 | 00:04:13,570 --> 00:04:17,010 384 | >> We might find it immediately the 385 | first time we make a division, but, 386 | 387 | 82 388 | 00:04:17,010 --> 00:04:19,339 389 | again, remember that 390 | although binary search is 391 | 392 | 83 393 | 00:04:19,339 --> 00:04:24,030 394 | substantially better than linear search 395 | by virtue of being log n versus n, 396 | 397 | 84 398 | 00:04:24,030 --> 00:04:27,110 399 | you might have to go through the work 400 | of sorting your array first, which 401 | 402 | 85 403 | 00:04:27,110 --> 00:04:32,010 404 | might make it less effective depending 405 | on the size of the iterating sorted. 406 | 407 | 86 408 | 00:04:32,010 --> 00:04:35,250 409 | >> I'm Doug Lloyd, this is CS50. 410 | 411 | 87 412 | 00:04:35,250 --> 00:04:36,757 413 | -------------------------------------------------------------------------------- /2015/en/sections/bubble_sort.srt: -------------------------------------------------------------------------------- 1 | 1 2 | 00:00:00,000 --> 00:00:03,360 3 | >> [MUSIC PLAYING] 4 | 5 | 2 6 | 00:00:03,360 --> 00:00:04,522 7 | 8 | 3 9 | 00:00:04,522 --> 00:00:06,730 10 | DOUG LLOYD: All right, so 11 | bubble sort is an algorithm 12 | 13 | 4 14 | 00:00:06,730 --> 00:00:08,730 15 | you can use to sort a set of elements. 16 | 17 | 5 18 | 00:00:08,730 --> 00:00:10,850 19 | Let's take a look at how it works. 20 | 21 | 6 22 | 00:00:10,850 --> 00:00:13,240 23 | >> So the basic idea behind 24 | bubble sort is this. 25 | 26 | 7 27 | 00:00:13,240 --> 00:00:17,340 28 | We generally want to move higher 29 | valued elements generally to the right, 30 | 31 | 8 32 | 00:00:17,340 --> 00:00:20,340 33 | and lower valued elements generally 34 | to the left, as we would expect. 35 | 36 | 9 37 | 00:00:20,340 --> 00:00:23,256 38 | We want the lower things to be at 39 | the beginning, and the higher things 40 | 41 | 10 42 | 00:00:23,256 --> 00:00:24,970 43 | to be at the end. 44 | 45 | 11 46 | 00:00:24,970 --> 00:00:26,130 47 | >> How do we do this? 48 | 49 | 12 50 | 00:00:26,130 --> 00:00:28,040 51 | Well in pseudocode code, 52 | we could say, let's 53 | 54 | 13 55 | 00:00:28,040 --> 00:00:30,320 56 | set a swap counter to a non-zero value. 57 | 58 | 14 59 | 00:00:30,320 --> 00:00:32,570 60 | We'll see why we do that in a second. 61 | 62 | 15 63 | 00:00:32,570 --> 00:00:36,090 64 | And then we repeat the following 65 | process until the swap counter is 0, 66 | 67 | 16 68 | 00:00:36,090 --> 00:00:39,910 69 | or until we make no swaps at all. 70 | 71 | 17 72 | 00:00:39,910 --> 00:00:43,170 73 | >> Reset the swap counter to 74 | 0 if it's not already 0. 75 | 76 | 18 77 | 00:00:43,170 --> 00:00:46,420 78 | Then look at every 79 | adjacent pair of elements. 80 | 81 | 19 82 | 00:00:46,420 --> 00:00:49,550 83 | If those two elements are 84 | not in order, swap them, 85 | 86 | 20 87 | 00:00:49,550 --> 00:00:51,620 88 | and add 1 to the swap counter. 89 | 90 | 21 91 | 00:00:51,620 --> 00:00:53,870 92 | If you're thinking about 93 | this before you visualize it, 94 | 95 | 22 96 | 00:00:53,870 --> 00:00:57,471 97 | notice that this will move lower 98 | valued elements to the left 99 | 100 | 23 101 | 00:00:57,471 --> 00:01:00,720 102 | and higher valued elements to the right, 103 | effectively doing what we want to do, 104 | 105 | 24 106 | 00:01:00,720 --> 00:01:03,940 107 | which is move those groups 108 | of elements in that way. 109 | 110 | 25 111 | 00:01:03,940 --> 00:01:07,035 112 | Let's visualize how this 113 | might look using our array 114 | 115 | 26 116 | 00:01:07,035 --> 00:01:10,504 117 | that we used to test 118 | out these algorithms. 119 | 120 | 27 121 | 00:01:10,504 --> 00:01:13,420 122 | We have an unsorted array here again, 123 | indicated by all of the elements 124 | 125 | 28 126 | 00:01:13,420 --> 00:01:14,840 127 | being in red. 128 | 129 | 29 130 | 00:01:14,840 --> 00:01:17,970 131 | And I set my swap counter 132 | to a nonzero value. 133 | 134 | 30 135 | 00:01:17,970 --> 00:01:20,610 136 | I arbitrarily chose 137 | negative 1-- it's not 0. 138 | 139 | 31 140 | 00:01:20,610 --> 00:01:23,840 141 | We want to repeat this process 142 | until the swap counter is 0. 143 | 144 | 32 145 | 00:01:23,840 --> 00:01:26,540 146 | This is why I set my swap 147 | counter to some non-zero value, 148 | 149 | 33 150 | 00:01:26,540 --> 00:01:29,400 151 | because otherwise the 152 | swap counter would be 0. 153 | 154 | 34 155 | 00:01:29,400 --> 00:01:31,610 156 | We wouldn't even begin the 157 | process of the algorithm. 158 | 159 | 35 160 | 00:01:31,610 --> 00:01:33,610 161 | So again, the steps are-- 162 | reset the swap counter 163 | 164 | 36 165 | 00:01:33,610 --> 00:01:37,900 166 | to 0, then look at every adjacent 167 | pair, and if they're out of order, 168 | 169 | 37 170 | 00:01:37,900 --> 00:01:40,514 171 | swap them, and add 1 172 | to the swap counter. 173 | 174 | 38 175 | 00:01:40,514 --> 00:01:41,680 176 | So let's begin this process. 177 | 178 | 39 179 | 00:01:41,680 --> 00:01:44,430 180 | So the first thing we do is 181 | we set the swap counter to 0, 182 | 183 | 40 184 | 00:01:44,430 --> 00:01:46,660 185 | and then we start looking 186 | at each adjacent pair. 187 | 188 | 41 189 | 00:01:46,660 --> 00:01:49,140 190 | >> So we first start looking at 5 and 2. 191 | 192 | 42 193 | 00:01:49,140 --> 00:01:52,410 194 | We see that they are out of 195 | order and so we swap them. 196 | 197 | 43 198 | 00:01:52,410 --> 00:01:53,830 199 | And we add 1 to the swap counter. 200 | 201 | 44 202 | 00:01:53,830 --> 00:01:57,860 203 | So now our swap counter is 1, 204 | and 2 and 5 have been switched. 205 | 206 | 45 207 | 00:01:57,860 --> 00:01:59,370 208 | Now we repeat the process again. 209 | 210 | 46 211 | 00:01:59,370 --> 00:02:03,540 212 | >> We look at the next adjacent pair, 213 | 5 and 1-- they're also out of order, 214 | 215 | 47 216 | 00:02:03,540 --> 00:02:06,960 217 | so we swap them and add 218 | 1 to the swap counter. 219 | 220 | 48 221 | 00:02:06,960 --> 00:02:08,900 222 | Then we look at 5 and 3. 223 | 224 | 49 225 | 00:02:08,900 --> 00:02:13,830 226 | They are out of order, so we swap 227 | them and we add 1 to the swap counter. 228 | 229 | 50 230 | 00:02:13,830 --> 00:02:15,550 231 | Then we look at 5 and 6. 232 | 233 | 51 234 | 00:02:15,550 --> 00:02:18,630 235 | They're in order, so we don't actually 236 | need to swap anything this time. 237 | 238 | 52 239 | 00:02:18,630 --> 00:02:20,250 240 | Then we look at 6 and 4. 241 | 242 | 53 243 | 00:02:20,250 --> 00:02:24,920 244 | They're also out of order, so we swap 245 | them and we add 1 to the swap counter. 246 | 247 | 54 248 | 00:02:24,920 --> 00:02:26,230 249 | >> Now notice what's happened. 250 | 251 | 55 252 | 00:02:26,230 --> 00:02:29,514 253 | We've moved 6 all the way to the end. 254 | 255 | 56 256 | 00:02:29,514 --> 00:02:32,180 257 | So in selection sort, if you've 258 | seen that video, what we did was 259 | 260 | 57 261 | 00:02:32,180 --> 00:02:35,290 262 | we ended up moving the 263 | smallest elements in building 264 | 265 | 58 266 | 00:02:35,290 --> 00:02:39,640 267 | the sorted array essentially from 268 | left to right, smallest to largest. 269 | 270 | 59 271 | 00:02:39,640 --> 00:02:43,200 272 | In the case of bubble sort, if we're 273 | following this particular algorithm, 274 | 275 | 60 276 | 00:02:43,200 --> 00:02:46,720 277 | we're actually going to be building 278 | the sorted array from right 279 | 280 | 61 281 | 00:02:46,720 --> 00:02:49,100 282 | to left, largest to smallest. 283 | 284 | 62 285 | 00:02:49,100 --> 00:02:53,840 286 | We have effectively bubbled 6, the 287 | largest value, all the way to the end. 288 | 289 | 63 290 | 00:02:53,840 --> 00:02:56,165 291 | >> And so we can now declare 292 | that that is sorted, 293 | 294 | 64 295 | 00:02:56,165 --> 00:02:59,130 296 | and in future iterations-- 297 | going through the array again-- 298 | 299 | 65 300 | 00:02:59,130 --> 00:03:01,280 301 | we don't have to consider 6 anymore. 302 | 303 | 66 304 | 00:03:01,280 --> 00:03:03,850 305 | We only have to consider 306 | the unsorted elements 307 | 308 | 67 309 | 00:03:03,850 --> 00:03:06,299 310 | when we're looking at adjacent pairs. 311 | 312 | 68 313 | 00:03:06,299 --> 00:03:08,340 314 | So we have finished one 315 | pass through bubble sort. 316 | 317 | 69 318 | 00:03:08,340 --> 00:03:11,941 319 | So now we go back to the question, 320 | repeat until the swap counter is 0. 321 | 322 | 70 323 | 00:03:11,941 --> 00:03:13,690 324 | Well the swap counter 325 | is 4, so we're going 326 | 327 | 71 328 | 00:03:13,690 --> 00:03:15,410 329 | to keep repeating this process again. 330 | 331 | 72 332 | 00:03:15,410 --> 00:03:19,180 333 | >> We're going to reset the swap counter 334 | to 0, and look at each adjacent pair. 335 | 336 | 73 337 | 00:03:19,180 --> 00:03:21,890 338 | So we start with 2 and 1-- they're 339 | out of order, so we swap them 340 | 341 | 74 342 | 00:03:21,890 --> 00:03:23,620 343 | and we add 1 to the swap counter. 344 | 345 | 75 346 | 00:03:23,620 --> 00:03:25,490 347 | 2 and 3, they're in order. 348 | 349 | 76 350 | 00:03:25,490 --> 00:03:27,060 351 | We don't need to do anything. 352 | 353 | 77 354 | 00:03:27,060 --> 00:03:28,420 355 | 3 and 5 are in order. 356 | 357 | 78 358 | 00:03:28,420 --> 00:03:30,150 359 | We don't need to do anything there. 360 | 361 | 79 362 | 00:03:30,150 --> 00:03:32,515 363 | >> 5 and 4, they are out 364 | of order, and so we 365 | 366 | 80 367 | 00:03:32,515 --> 00:03:35,130 368 | need to swap them and add 369 | 1 to the swap counter. 370 | 371 | 81 372 | 00:03:35,130 --> 00:03:38,880 373 | And now we've moved 5, 374 | the next largest element, 375 | 376 | 82 377 | 00:03:38,880 --> 00:03:40,920 378 | to the end of the unsorted portion. 379 | 380 | 83 381 | 00:03:40,920 --> 00:03:44,360 382 | So we can now call that 383 | part of the sorted portion. 384 | 385 | 84 386 | 00:03:44,360 --> 00:03:47,180 387 | >> Now you're looking at the 388 | screen and probably can tell, 389 | 390 | 85 391 | 00:03:47,180 --> 00:03:50,130 392 | as can I, that the array 393 | is sorted right now. 394 | 395 | 86 396 | 00:03:50,130 --> 00:03:51,820 397 | But we can't prove that yet. 398 | 399 | 87 400 | 00:03:51,820 --> 00:03:54,359 401 | We don't have a guarantee 402 | that it's sorted. 403 | 404 | 88 405 | 00:03:54,359 --> 00:03:56,900 406 | But this is where the swap 407 | counter's going to come into play. 408 | 409 | 89 410 | 00:03:56,900 --> 00:03:59,060 411 | >> So we've completed a pass. 412 | 413 | 90 414 | 00:03:59,060 --> 00:04:00,357 415 | The swap counter is 2. 416 | 417 | 91 418 | 00:04:00,357 --> 00:04:02,190 419 | So we're going to repeat 420 | this process again, 421 | 422 | 92 423 | 00:04:02,190 --> 00:04:04,290 424 | repeat until the swap counter is 0. 425 | 426 | 93 427 | 00:04:04,290 --> 00:04:05,550 428 | Reset the swap counter to 0. 429 | 430 | 94 431 | 00:04:05,550 --> 00:04:06,820 432 | So we'll reset it. 433 | 434 | 95 435 | 00:04:06,820 --> 00:04:09,810 436 | >> Now look at each adjacent pair. 437 | 438 | 96 439 | 00:04:09,810 --> 00:04:11,880 440 | That's in order, 1 and 2. 441 | 442 | 97 443 | 00:04:11,880 --> 00:04:13,590 444 | 2 and 3 are in order. 445 | 446 | 98 447 | 00:04:13,590 --> 00:04:15,010 448 | 3 and 4 are in order. 449 | 450 | 99 451 | 00:04:15,010 --> 00:04:19,250 452 | So at this point, notice we've completed 453 | looking at every adjacent pair, 454 | 455 | 100 456 | 00:04:19,250 --> 00:04:22,530 457 | but the swap counter is still 0. 458 | 459 | 101 460 | 00:04:22,530 --> 00:04:25,520 461 | >> If we don't have to switch 462 | any elements, then they 463 | 464 | 102 465 | 00:04:25,520 --> 00:04:28,340 466 | must be in order, by 467 | virtue of this process. 468 | 469 | 103 470 | 00:04:28,340 --> 00:04:32,000 471 | And so an efficiency of sorts, 472 | that we computer scientists love, 473 | 474 | 104 475 | 00:04:32,000 --> 00:04:35,560 476 | is we can now declare 477 | the entire array must 478 | 479 | 105 480 | 00:04:35,560 --> 00:04:38,160 481 | be sorted, because we didn't 482 | have to swap any elements. 483 | 484 | 106 485 | 00:04:38,160 --> 00:04:40,380 486 | That's pretty nice. 487 | 488 | 107 489 | 00:04:40,380 --> 00:04:43,260 490 | >> So what's the worst case 491 | scenario with bubble sort? 492 | 493 | 108 494 | 00:04:43,260 --> 00:04:46,240 495 | In the worst case the array is 496 | in completely reverse order, 497 | 498 | 109 499 | 00:04:46,240 --> 00:04:49,870 500 | and so we have to bubble each 501 | of the large elements all 502 | 503 | 110 504 | 00:04:49,870 --> 00:04:51,780 505 | the way across the array. 506 | 507 | 111 508 | 00:04:51,780 --> 00:04:55,350 509 | And we effectively also have to 510 | bubble all of the small elements back 511 | 512 | 112 513 | 00:04:55,350 --> 00:04:57,050 514 | all the way across the array, too. 515 | 516 | 113 517 | 00:04:57,050 --> 00:05:01,950 518 | So each of the n elements has to move 519 | across all of the other n elements. 520 | 521 | 114 522 | 00:05:01,950 --> 00:05:04,102 523 | So that's the worst case scenario. 524 | 525 | 115 526 | 00:05:04,102 --> 00:05:05,810 527 | In the best case 528 | scenario though, this is 529 | 530 | 116 531 | 00:05:05,810 --> 00:05:07,880 532 | slightly different from selection sort. 533 | 534 | 117 535 | 00:05:07,880 --> 00:05:10,040 536 | The array is already 537 | sorted when we go in. 538 | 539 | 118 540 | 00:05:10,040 --> 00:05:12,550 541 | We don't have to make any 542 | swaps on the first pass. 543 | 544 | 119 545 | 00:05:12,550 --> 00:05:14,940 546 | So we might have to look 547 | at fewer elements, right? 548 | 549 | 120 550 | 00:05:14,940 --> 00:05:18,580 551 | We don't have to repeat this 552 | process a number of times over. 553 | 554 | 121 555 | 00:05:18,580 --> 00:05:19,540 556 | >> So what does that mean? 557 | 558 | 122 559 | 00:05:19,540 --> 00:05:22,390 560 | So what's the worst case scenario 561 | for bubble sort, and what's 562 | 563 | 123 564 | 00:05:22,390 --> 00:05:25,330 565 | the best case scenario for bubble sort? 566 | 567 | 124 568 | 00:05:25,330 --> 00:05:27,770 569 | Did you guess this? 570 | 571 | 125 572 | 00:05:27,770 --> 00:05:32,420 573 | In the worst case you have to iterate 574 | across all the n elements n times. 575 | 576 | 126 577 | 00:05:32,420 --> 00:05:34,220 578 | So the worst case is n squared. 579 | 580 | 127 581 | 00:05:34,220 --> 00:05:36,550 582 | >> If the array is perfectly 583 | sorted though, you only 584 | 585 | 128 586 | 00:05:36,550 --> 00:05:38,580 587 | have to look at each 588 | of the elements once. 589 | 590 | 129 591 | 00:05:38,580 --> 00:05:42,670 592 | And if the swap counter is still 0, 593 | you can say this array is sorted. 594 | 595 | 130 596 | 00:05:42,670 --> 00:05:45,780 597 | And so in the best case, this is 598 | actually better than selection 599 | 600 | 131 601 | 00:05:45,780 --> 00:05:49,230 602 | sort-- it's omega of n. 603 | 604 | 132 605 | 00:05:49,230 --> 00:05:50,270 606 | >> I'm Doug Lloyd. 607 | 608 | 133 609 | 00:05:50,270 --> 00:05:52,140 610 | This is CS50. 611 | 612 | 134 613 | 00:05:52,140 --> 00:05:54,382 614 | -------------------------------------------------------------------------------- /2015/en/sections/call_stack.srt: -------------------------------------------------------------------------------- 1 | 1 2 | 00:00:00,000 --> 00:00:05,587 3 | 4 | 2 5 | 00:00:05,587 --> 00:00:07,670 6 | DOUG LLOYD: If you've seen 7 | the video on recursion, 8 | 9 | 3 10 | 00:00:07,670 --> 00:00:10,170 11 | the whole process might have 12 | seemed a little bit magical. 13 | 14 | 4 15 | 00:00:10,170 --> 00:00:10,930 16 | How does it work? 17 | 18 | 5 19 | 00:00:10,930 --> 00:00:15,010 20 | How do the functions know that they 21 | need to wait and wait for another value 22 | 23 | 6 24 | 00:00:15,010 --> 00:00:19,150 25 | to return from a different function 26 | call in order to get the result we want? 27 | 28 | 7 29 | 00:00:19,150 --> 00:00:22,550 30 | >> Well, the reason this works is because 31 | of something known as the call stack. 32 | 33 | 8 34 | 00:00:22,550 --> 00:00:26,360 35 | When you call a function, the 36 | system sets aside space in memory 37 | 38 | 9 39 | 00:00:26,360 --> 00:00:28,120 40 | for that function to do its work. 41 | 42 | 10 43 | 00:00:28,120 --> 00:00:31,720 44 | And we call these chunks of memory that 45 | are being set aside for each function 46 | 47 | 11 48 | 00:00:31,720 --> 00:00:35,670 49 | call a stack frame or a function frame. 50 | 51 | 12 52 | 00:00:35,670 --> 00:00:38,290 53 | And as you might expect, 54 | these stack frames 55 | 56 | 13 57 | 00:00:38,290 --> 00:00:41,000 58 | live on the stack part of memory. 59 | 60 | 14 61 | 00:00:41,000 --> 00:00:43,960 62 | 63 | 15 64 | 00:00:43,960 --> 00:00:47,540 65 | >> More than one function stack frame 66 | can exist in memory at a given time. 67 | 68 | 16 69 | 00:00:47,540 --> 00:00:51,240 70 | If main calls a function move, 71 | and move calls direction, 72 | 73 | 17 74 | 00:00:51,240 --> 00:00:54,460 75 | all three functions have open frames. 76 | 77 | 18 78 | 00:00:54,460 --> 00:00:57,350 79 | But they don't all have active frames. 80 | 81 | 19 82 | 00:00:57,350 --> 00:00:59,410 83 | These frames are arranged in a stack. 84 | 85 | 20 86 | 00:00:59,410 --> 00:01:01,820 87 | And the frame from the 88 | most recently called 89 | 90 | 21 91 | 00:01:01,820 --> 00:01:04,390 92 | function is always on top of the stack. 93 | 94 | 22 95 | 00:01:04,390 --> 00:01:07,150 96 | And that is always the active frame. 97 | 98 | 23 99 | 00:01:07,150 --> 00:01:10,420 100 | There's only really ever one 101 | function that's active at a time. 102 | 103 | 24 104 | 00:01:10,420 --> 00:01:12,420 105 | It's the one on top of the stack. 106 | 107 | 25 108 | 00:01:12,420 --> 00:01:17,620 109 | >> When a function calls another 110 | function, it sort of presses pause. 111 | 112 | 26 113 | 00:01:17,620 --> 00:01:20,590 114 | It sort of is on hold, waiting. 115 | 116 | 27 117 | 00:01:20,590 --> 00:01:24,050 118 | And another stack frame is pushed 119 | onto the stack on top of it. 120 | 121 | 28 122 | 00:01:24,050 --> 00:01:26,150 123 | And that becomes the active frame. 124 | 125 | 29 126 | 00:01:26,150 --> 00:01:28,600 127 | And the frame immediately 128 | below it needs to wait 129 | 130 | 30 131 | 00:01:28,600 --> 00:01:33,560 132 | until it is again the active frame 133 | before it can resume its work. 134 | 135 | 31 136 | 00:01:33,560 --> 00:01:35,870 137 | When a function is 138 | complete and it's done, 139 | 140 | 32 141 | 00:01:35,870 --> 00:01:37,720 142 | its frame is popped off the stack. 143 | 144 | 33 145 | 00:01:37,720 --> 00:01:38,950 146 | That's the terminology. 147 | 148 | 34 149 | 00:01:38,950 --> 00:01:41,110 150 | And the frame immediately 151 | below it, as I just said, 152 | 153 | 35 154 | 00:01:41,110 --> 00:01:42,880 155 | becomes the new active frame. 156 | 157 | 36 158 | 00:01:42,880 --> 00:01:45,960 159 | >> And if it calls another function, 160 | it's going to pause again. 161 | 162 | 37 163 | 00:01:45,960 --> 00:01:49,290 164 | That new function's stack frame will 165 | be pushed onto the top of the stack. 166 | 167 | 38 168 | 00:01:49,290 --> 00:01:50,650 169 | It'll do its work. 170 | 171 | 39 172 | 00:01:50,650 --> 00:01:52,100 173 | It might pop back off. 174 | 175 | 40 176 | 00:01:52,100 --> 00:01:55,630 177 | And the other function 178 | below it can resume again. 179 | 180 | 41 181 | 00:01:55,630 --> 00:02:00,080 182 | >> So let's go through this again, looking 183 | at the idea of the factorial function 184 | 185 | 42 186 | 00:02:00,080 --> 00:02:03,070 187 | that we defined in the 188 | recursion video to see 189 | 190 | 43 191 | 00:02:03,070 --> 00:02:07,770 192 | exactly how the magic behind this 193 | recursive process is taking place. 194 | 195 | 44 196 | 00:02:07,770 --> 00:02:09,870 197 | So this is our entire file, right? 198 | 199 | 45 200 | 00:02:09,870 --> 00:02:14,000 201 | We defined two 202 | functions-- main and fact. 203 | 204 | 46 205 | 00:02:14,000 --> 00:02:15,980 206 | And as we might expect, 207 | any C program is going 208 | 209 | 47 210 | 00:02:15,980 --> 00:02:18,470 211 | to start at the first line of main. 212 | 213 | 48 214 | 00:02:18,470 --> 00:02:21,660 215 | >> So we create a new stack frame for main. 216 | 217 | 49 218 | 00:02:21,660 --> 00:02:23,320 219 | And it's going to begin running. 220 | 221 | 50 222 | 00:02:23,320 --> 00:02:25,270 223 | Main calls printf. 224 | 225 | 51 226 | 00:02:25,270 --> 00:02:29,390 227 | And printf is going to 228 | print out factorial of 5. 229 | 230 | 52 231 | 00:02:29,390 --> 00:02:31,440 232 | Well, it doesn't know 233 | what factorial of 5 is, 234 | 235 | 53 236 | 00:02:31,440 --> 00:02:35,620 237 | and so this call is already 238 | depending on another function call. 239 | 240 | 54 241 | 00:02:35,620 --> 00:02:37,270 242 | So main is going to pause right there. 243 | 244 | 55 245 | 00:02:37,270 --> 00:02:39,103 246 | I'm gonna leave its 247 | arrow right there, color 248 | 249 | 56 250 | 00:02:39,103 --> 00:02:41,360 251 | it the same color as the 252 | stack frame on the right, 253 | 254 | 57 255 | 00:02:41,360 --> 00:02:47,720 256 | to indicate that main is going to freeze 257 | here while factorial of 5 is called. 258 | 259 | 58 260 | 00:02:47,720 --> 00:02:49,300 261 | >> So factorial of 5 is called. 262 | 263 | 59 264 | 00:02:49,300 --> 00:02:53,160 265 | And it's going to start at the very 266 | beginning of the factorial function. 267 | 268 | 60 269 | 00:02:53,160 --> 00:02:55,440 270 | It asks the question am I equal to 1? 271 | 272 | 61 273 | 00:02:55,440 --> 00:02:56,810 274 | Is 5 equal to 1? 275 | 276 | 62 277 | 00:02:56,810 --> 00:02:57,410 278 | Well, no. 279 | 280 | 63 281 | 00:02:57,410 --> 00:03:01,110 282 | So it's going to go down to 283 | the else part, return n times 284 | 285 | 64 286 | 00:03:01,110 --> 00:03:02,990 287 | factorial of n minus 1. 288 | 289 | 65 290 | 00:03:02,990 --> 00:03:03,490 291 | Well, OK. 292 | 293 | 66 294 | 00:03:03,490 --> 00:03:07,070 295 | >> So now, factorial of 5 is 296 | depending on another call 297 | 298 | 67 299 | 00:03:07,070 --> 00:03:09,740 300 | to factorial, passing 301 | in 4 as the parameter. 302 | 303 | 68 304 | 00:03:09,740 --> 00:03:14,210 305 | And so the factorial of 306 | 5 frame, that red frame, 307 | 308 | 69 309 | 00:03:14,210 --> 00:03:17,160 310 | is going to freeze right there 311 | at that line I've indicated 312 | 313 | 70 314 | 00:03:17,160 --> 00:03:21,914 315 | and wait for factorial of 4 to finish 316 | what it needs to do so that then it 317 | 318 | 71 319 | 00:03:21,914 --> 00:03:23,330 320 | can become the active frame again. 321 | 322 | 72 323 | 00:03:23,330 --> 00:03:26,890 324 | >> So factorial of 4 starts at 325 | the beginning of factorial. 326 | 327 | 73 328 | 00:03:26,890 --> 00:03:28,556 329 | Is 4 equal to 1? 330 | 331 | 74 332 | 00:03:28,556 --> 00:03:30,180 333 | No, so it's going to do the same thing. 334 | 335 | 75 336 | 00:03:30,180 --> 00:03:31,590 337 | It's going to go down the else branch. 338 | 339 | 76 340 | 00:03:31,590 --> 00:03:33,240 341 | It's going to get to that line of code. 342 | 343 | 77 344 | 00:03:33,240 --> 00:03:35,710 345 | OK, I'm going to return four times. 346 | 347 | 78 348 | 00:03:35,710 --> 00:03:41,270 349 | Oh, factorial of 3-- so factorial of 350 | 4 depends on factorial of 3 finishing. 351 | 352 | 79 353 | 00:03:41,270 --> 00:03:43,055 354 | >> And so it needs to call factorial of 3. 355 | 356 | 80 357 | 00:03:43,055 --> 00:03:45,180 358 | And that's gonna go through 359 | the same process again. 360 | 361 | 81 362 | 00:03:45,180 --> 00:03:48,200 363 | It starts through, gets here. 364 | 365 | 82 366 | 00:03:48,200 --> 00:03:50,980 367 | Factorial of 3 depends 368 | on factorial of 1. 369 | 370 | 83 371 | 00:03:50,980 --> 00:03:53,750 372 | So factorial of 2 starts, gets here. 373 | 374 | 84 375 | 00:03:53,750 --> 00:03:56,310 376 | It depends on factorial of 1. 377 | 378 | 85 379 | 00:03:56,310 --> 00:03:57,430 380 | Factorial of 1 starts. 381 | 382 | 86 383 | 00:03:57,430 --> 00:03:57,650 384 | >> OK. 385 | 386 | 87 387 | 00:03:57,650 --> 00:03:59,775 388 | So now, we're getting 389 | somewhere interesting, right? 390 | 391 | 88 392 | 00:03:59,775 --> 00:04:02,190 393 | So now, 1 is equal to 1. 394 | 395 | 89 396 | 00:04:02,190 --> 00:04:05,130 397 | And so we return 1. 398 | 399 | 90 400 | 00:04:05,130 --> 00:04:06,770 401 | At this point, we are returning. 402 | 403 | 91 404 | 00:04:06,770 --> 00:04:07,880 405 | The function's done. 406 | 407 | 92 408 | 00:04:07,880 --> 00:04:11,140 409 | It's behavior is-- there's 410 | nothing else for it to do, 411 | 412 | 93 413 | 00:04:11,140 --> 00:04:17,006 414 | and so the stack frame for 415 | factorial of 1 pops off. 416 | 417 | 94 418 | 00:04:17,006 --> 00:04:17,589 419 | It's finished. 420 | 421 | 95 422 | 00:04:17,589 --> 00:04:19,480 423 | It returned 1. 424 | 425 | 96 426 | 00:04:19,480 --> 00:04:23,370 427 | And now, factorial of 2, which 428 | was the frame immediately below it 429 | 430 | 97 431 | 00:04:23,370 --> 00:04:26,160 432 | in the stack, becomes the active frame. 433 | 434 | 98 435 | 00:04:26,160 --> 00:04:29,030 436 | >> And it can pick up 437 | exactly where it left off. 438 | 439 | 99 440 | 00:04:29,030 --> 00:04:32,240 441 | It's been waiting for a factorial 442 | of 1 to finish its work. 443 | 444 | 100 445 | 00:04:32,240 --> 00:04:33,610 446 | It has now finished. 447 | 448 | 101 449 | 00:04:33,610 --> 00:04:35,510 450 | And so here we are. 451 | 452 | 102 453 | 00:04:35,510 --> 00:04:38,080 454 | >> Factorial of 1 returned a value of 1. 455 | 456 | 103 457 | 00:04:38,080 --> 00:04:42,430 458 | So factorial of 2 can 459 | say return 2 times 1. 460 | 461 | 104 462 | 00:04:42,430 --> 00:04:43,680 463 | Its work is now done. 464 | 465 | 105 466 | 00:04:43,680 --> 00:04:49,110 467 | It's returned 2 to factorial 468 | of 3, which was waiting for it. 469 | 470 | 106 471 | 00:04:49,110 --> 00:04:53,370 472 | Factorial of 3 is now the top frame, 473 | the active frame in the stack. 474 | 475 | 107 476 | 00:04:53,370 --> 00:04:58,617 477 | And so it says, OK, well, I'm going 478 | to return 3 times 2, which is 6. 479 | 480 | 108 481 | 00:04:58,617 --> 00:05:00,700 482 | And I'm going to give that 483 | value back to factorial 484 | 485 | 109 486 | 00:05:00,700 --> 00:05:03,430 487 | of 4, which has been waiting for me. 488 | 489 | 110 490 | 00:05:03,430 --> 00:05:04,500 491 | I'm done. 492 | 493 | 111 494 | 00:05:04,500 --> 00:05:09,410 495 | Factorial of 3 pops off the stack, and 496 | factorial of 4 is now the active frame. 497 | 498 | 112 499 | 00:05:09,410 --> 00:05:13,510 500 | >> 4 says, OK, I'm going to return 4 times 501 | the factorial of 3, which was six. 502 | 503 | 113 504 | 00:05:13,510 --> 00:05:15,980 505 | That was of value that 506 | factorial of 3 returned. 507 | 508 | 114 509 | 00:05:15,980 --> 00:05:19,010 510 | And so 4 times 6 is 24. 511 | 512 | 115 513 | 00:05:19,010 --> 00:05:20,990 514 | And I'm going to pass 515 | that back to factorial 516 | 517 | 116 518 | 00:05:20,990 --> 00:05:23,160 519 | of 5, which has been waiting for me. 520 | 521 | 117 522 | 00:05:23,160 --> 00:05:25,270 523 | Factorial of 5 is now the active frame. 524 | 525 | 118 526 | 00:05:25,270 --> 00:05:30,700 527 | It's going to return 5 times 528 | factorial of 4-- 5 times 24, or 120-- 529 | 530 | 119 531 | 00:05:30,700 --> 00:05:32,722 532 | and give that value 533 | back to main, which has 534 | 535 | 120 536 | 00:05:32,722 --> 00:05:35,680 537 | been waiting very patiently for a 538 | long time at the bottom of the stack. 539 | 540 | 121 541 | 00:05:35,680 --> 00:05:36,640 542 | >> It's where it started. 543 | 544 | 122 545 | 00:05:36,640 --> 00:05:37,670 546 | It made this call. 547 | 548 | 123 549 | 00:05:37,670 --> 00:05:39,400 550 | Several frames took over at the top. 551 | 552 | 124 553 | 00:05:39,400 --> 00:05:41,890 554 | It is now back on top of the stack. 555 | 556 | 125 557 | 00:05:41,890 --> 00:05:43,450 558 | It's the active frame. 559 | 560 | 126 561 | 00:05:43,450 --> 00:05:47,810 562 | So main got the value 120 563 | back from factorial of 5. 564 | 565 | 127 566 | 00:05:47,810 --> 00:05:50,750 567 | It's been waiting to 568 | print out that value. 569 | 570 | 128 571 | 00:05:50,750 --> 00:05:51,657 572 | And then it's done. 573 | 574 | 129 575 | 00:05:51,657 --> 00:05:53,240 576 | There's no more lines of code in main. 577 | 578 | 130 579 | 00:05:53,240 --> 00:05:56,800 580 | So main's frame pops off 581 | the stack, and we're done. 582 | 583 | 131 584 | 00:05:56,800 --> 00:05:58,992 585 | >> And that's how recursion works. 586 | 587 | 132 588 | 00:05:58,992 --> 00:06:00,200 589 | That's how stack frames work. 590 | 591 | 133 592 | 00:06:00,200 --> 00:06:03,120 593 | Those function calls 594 | that happened previously 595 | 596 | 134 597 | 00:06:03,120 --> 00:06:06,620 598 | are just on pause, waiting 599 | for the subsequent calls 600 | 601 | 135 602 | 00:06:06,620 --> 00:06:12,050 603 | to finish so they can become the active 604 | frame and finish what they need to do. 605 | 606 | 136 607 | 00:06:12,050 --> 00:06:13,060 608 | >> I'm Doug Lloyd. 609 | 610 | 137 611 | 00:06:13,060 --> 00:06:14,880 612 | This is CS50. 613 | 614 | 138 615 | 00:06:14,880 --> 00:06:16,580 616 | -------------------------------------------------------------------------------- /2015/en/sections/custom_types.srt: -------------------------------------------------------------------------------- 1 | 1 2 | 00:00:00,000 --> 00:00:04,970 3 | 4 | 2 5 | 00:00:04,970 --> 00:00:07,220 6 | DOUG LLOYD: So if you've 7 | seen our video on structures, 8 | 9 | 3 10 | 00:00:07,220 --> 00:00:10,950 11 | you already know that we have the 12 | ability to define our own data types. 13 | 14 | 4 15 | 00:00:10,950 --> 00:00:14,530 16 | But if you've used structures, you know 17 | that sometimes using those data types 18 | 19 | 5 20 | 00:00:14,530 --> 00:00:16,446 21 | can actually be a little 22 | cumbersome because we 23 | 24 | 6 25 | 00:00:16,446 --> 00:00:19,210 26 | have to use the struct keyword 27 | when we're working with them-- 28 | 29 | 7 30 | 00:00:19,210 --> 00:00:21,257 31 | struct car or struct student. 32 | 33 | 8 34 | 00:00:21,257 --> 00:00:23,090 35 | That's a lot to type 36 | if we just want to have 37 | 38 | 9 39 | 00:00:23,090 --> 00:00:24,830 40 | something simple, like a structure. 41 | 42 | 10 43 | 00:00:24,830 --> 00:00:26,390 44 | We want to have-- we want to 45 | be able to work with things 46 | 47 | 11 48 | 00:00:26,390 --> 00:00:29,350 49 | a little more shorthand way, 50 | like int or char, something a lot 51 | 52 | 12 53 | 00:00:29,350 --> 00:00:31,240 54 | more convenient to type. 55 | 56 | 13 57 | 00:00:31,240 --> 00:00:33,100 58 | >> Fortunately, there's 59 | a way to do this in C, 60 | 61 | 14 62 | 00:00:33,100 --> 00:00:37,150 63 | with something called typedef, which is 64 | a way to create shorthand or rewritten 65 | 66 | 15 67 | 00:00:37,150 --> 00:00:38,640 68 | names for data types. 69 | 70 | 16 71 | 00:00:38,640 --> 00:00:40,720 72 | You can rewrite data 73 | types that already exist, 74 | 75 | 17 76 | 00:00:40,720 --> 00:00:43,970 77 | or you can write data types of your own. 78 | 79 | 18 80 | 00:00:43,970 --> 00:00:46,890 81 | >> The first thing you do is you 82 | define a type in the normal way, 83 | 84 | 19 85 | 00:00:46,890 --> 00:00:52,271 86 | and then you just alias it to something 87 | else-- typedef old name new name. 88 | 89 | 20 90 | 00:00:52,271 --> 00:00:53,520 91 | Pretty straightforward, right? 92 | 93 | 21 94 | 00:00:53,520 --> 00:00:56,240 95 | So we could typedef for example, 96 | the already existing data 97 | 98 | 22 99 | 00:00:56,240 --> 00:01:00,266 100 | type of unsigned char as byte. 101 | 102 | 23 103 | 00:01:00,266 --> 00:01:03,140 104 | And then, from now on, after we've 105 | made this type definition-- again, 106 | 107 | 24 108 | 00:01:03,140 --> 00:01:07,570 109 | which is usually going to be at the top 110 | of our dot C files, or in a dot H file 111 | 112 | 25 113 | 00:01:07,570 --> 00:01:10,590 114 | separately, we can just 115 | use bite everywhere 116 | 117 | 26 118 | 00:01:10,590 --> 00:01:12,180 119 | we would have used unsigned char. 120 | 121 | 27 122 | 00:01:12,180 --> 00:01:14,300 123 | That's a lot shorter to type. 124 | 125 | 28 126 | 00:01:14,300 --> 00:01:19,280 127 | >> In CS50's library, we do this-- 128 | we typedef char star as string. 129 | 130 | 29 131 | 00:01:19,280 --> 00:01:21,400 132 | Because we abstracted 133 | away the idea of pointers. 134 | 135 | 30 136 | 00:01:21,400 --> 00:01:25,072 137 | And the fact that a string is really 138 | a pointer to the first character-- 139 | 140 | 31 141 | 00:01:25,072 --> 00:01:26,780 142 | an array of characters, 143 | because it's just 144 | 145 | 32 146 | 00:01:26,780 --> 00:01:29,863 147 | so confusing to get your head around 148 | that-- but in fact that's what we do. 149 | 150 | 33 151 | 00:01:29,863 --> 00:01:35,140 152 | And this line of code actually exists 153 | in CS50 dot H typedef char star string, 154 | 155 | 34 156 | 00:01:35,140 --> 00:01:39,021 157 | just to make that a little less 158 | cumbersome to have to deal with. 159 | 160 | 35 161 | 00:01:39,021 --> 00:01:41,520 162 | Already you've seen probably a 163 | little bit of the value here, 164 | 165 | 36 166 | 00:01:41,520 --> 00:01:44,160 167 | but typedef becomes great 168 | when combined with structures, 169 | 170 | 37 171 | 00:01:44,160 --> 00:01:45,780 172 | as I alluded to earlier. 173 | 174 | 38 175 | 00:01:45,780 --> 00:01:48,550 176 | Structures have a two-word type name. 177 | 178 | 39 179 | 00:01:48,550 --> 00:01:52,020 180 | And so they can be really annoying 181 | to create variables of that type, 182 | 183 | 40 184 | 00:01:52,020 --> 00:01:56,310 185 | or [INAUDIBLE] of struct something, your 186 | lines can just get really, really long. 187 | 188 | 41 189 | 00:01:56,310 --> 00:01:59,400 190 | And so you can use typedef to come 191 | up with something a lot shorter. 192 | 193 | 42 194 | 00:01:59,400 --> 00:02:04,650 195 | >> So if I define a car as follows, I have 196 | my definition of a car-- struct car, 197 | 198 | 43 199 | 00:02:04,650 --> 00:02:07,230 200 | and then open curly brace, all 201 | the fields of my structure, 202 | 203 | 44 204 | 00:02:07,230 --> 00:02:11,030 205 | close curly brace, semi-colon-- 206 | after I've defined my data type, 207 | 208 | 45 209 | 00:02:11,030 --> 00:02:15,680 210 | I can typedef struct 211 | car as car underscore t. 212 | 213 | 46 214 | 00:02:15,680 --> 00:02:19,670 215 | And then when I've done that, now every 216 | time I would have otherwise used struct 217 | 218 | 47 219 | 00:02:19,670 --> 00:02:22,680 220 | car, I can just use car underscore t. 221 | 222 | 48 223 | 00:02:22,680 --> 00:02:26,480 224 | That's a lot shorter of a way to 225 | express this idea of this structure 226 | 227 | 49 228 | 00:02:26,480 --> 00:02:28,530 229 | that I just created. 230 | 231 | 50 232 | 00:02:28,530 --> 00:02:33,620 233 | >> Alternatively, because structures 234 | are so commonly used in typedef, 235 | 236 | 51 237 | 00:02:33,620 --> 00:02:37,980 238 | there's a-- you can actually define the 239 | type in between the start and the end. 240 | 241 | 52 242 | 00:02:37,980 --> 00:02:42,020 243 | So the typedef structure again is 244 | usually typedef, old name, new name, 245 | 246 | 53 247 | 00:02:42,020 --> 00:02:45,360 248 | where the names are already 249 | types that you've created. 250 | 251 | 54 252 | 00:02:45,360 --> 00:02:49,620 253 | But you can actually define a structure 254 | right in the middle of the typedef 255 | 256 | 55 257 | 00:02:49,620 --> 00:02:51,760 258 | instead of having to define 259 | it separately, and then 260 | 261 | 56 262 | 00:02:51,760 --> 00:02:52,990 263 | do a typedef of it. 264 | 265 | 57 266 | 00:02:52,990 --> 00:02:55,780 267 | And that would look just like 268 | this-- typedef struct car, 269 | 270 | 58 271 | 00:02:55,780 --> 00:02:59,957 272 | open curly brace, all of your field 273 | definitions, close curly brace, car t. 274 | 275 | 59 276 | 00:02:59,957 --> 00:03:03,290 277 | So the old name is all that stuff in the 278 | red, you're just defining the structure 279 | 280 | 60 281 | 00:03:03,290 --> 00:03:05,610 282 | and naming it at the same time. 283 | 284 | 61 285 | 00:03:05,610 --> 00:03:07,790 286 | And then the new name 287 | is car underscore t. 288 | 289 | 62 290 | 00:03:07,790 --> 00:03:10,150 291 | And so if we start to use 292 | this in code, previously I 293 | 294 | 63 295 | 00:03:10,150 --> 00:03:13,279 296 | might have said, struct 297 | car mycar semi-colon. 298 | 299 | 64 300 | 00:03:13,279 --> 00:03:14,820 301 | Well I don't have to do that anymore. 302 | 303 | 65 304 | 00:03:14,820 --> 00:03:20,265 305 | Now that I've used the typedef, I 306 | can just say car underscore t, mycar. 307 | 308 | 66 309 | 00:03:20,265 --> 00:03:22,640 310 | That's a lot shorter of a way 311 | to do it, and in fact, it's 312 | 313 | 67 314 | 00:03:22,640 --> 00:03:24,515 315 | going to be a lot more 316 | convenient, especially 317 | 318 | 68 319 | 00:03:24,515 --> 00:03:27,730 320 | as you start to use structures 321 | a lot more in your code. 322 | 323 | 69 324 | 00:03:27,730 --> 00:03:28,810 325 | >> I'm Doug Lloyd. 326 | 327 | 70 328 | 00:03:28,810 --> 00:03:30,640 329 | This is CS50. 330 | 331 | 71 332 | 00:03:30,640 --> 00:03:32,415 333 | -------------------------------------------------------------------------------- /2015/en/sections/insertion_sort.srt: -------------------------------------------------------------------------------- 1 | 1 2 | 00:00:00,000 --> 00:00:02,826 3 | >> [MUSIC PLAYING] 4 | 5 | 2 6 | 00:00:02,826 --> 00:00:05,660 7 | 8 | 3 9 | 00:00:05,660 --> 00:00:09,370 10 | >> DOUG LLOYD: So insertion sort is another 11 | algorithm we can use to sort an array. 12 | 13 | 4 14 | 00:00:09,370 --> 00:00:12,350 15 | The idea behind this algorithm 16 | is to build your sorted array 17 | 18 | 5 19 | 00:00:12,350 --> 00:00:19,670 20 | in place, shifting elements out of 21 | the way as you go, to make room. 22 | 23 | 6 24 | 00:00:19,670 --> 00:00:22,240 25 | This is slightly different 26 | from selection sort or bubble 27 | 28 | 7 29 | 00:00:22,240 --> 00:00:25,460 30 | sort, for example, where 31 | we're adjusting the locations, 32 | 33 | 8 34 | 00:00:25,460 --> 00:00:26,910 35 | where we're making swaps. 36 | 37 | 9 38 | 00:00:26,910 --> 00:00:29,760 39 | >> In this case what we're actually 40 | doing is sliding elements 41 | 42 | 10 43 | 00:00:29,760 --> 00:00:31,390 44 | over, out of the way. 45 | 46 | 11 47 | 00:00:31,390 --> 00:00:34,030 48 | How does this algorithm 49 | work in pseudocode? 50 | 51 | 12 52 | 00:00:34,030 --> 00:00:37,646 53 | Well let's just arbitrarily say that the 54 | first element of the array is sorted. 55 | 56 | 13 57 | 00:00:37,646 --> 00:00:38,770 58 | We're building it in place. 59 | 60 | 14 61 | 00:00:38,770 --> 00:00:42,660 62 | >> We're gonna go one element at a time and 63 | build it, and so the first thing we see 64 | 65 | 15 66 | 00:00:42,660 --> 00:00:43,890 67 | is a one element array. 68 | 69 | 16 70 | 00:00:43,890 --> 00:00:47,720 71 | And by definition, a one 72 | element array is sorted. 73 | 74 | 17 75 | 00:00:47,720 --> 00:00:50,850 76 | >> Then we'll repeat this process until-- 77 | we'll repeat the following process 78 | 79 | 18 80 | 00:00:50,850 --> 00:00:52,900 81 | until all of the elements are sorted. 82 | 83 | 19 84 | 00:00:52,900 --> 00:00:57,770 85 | Look at the next unsorted element and 86 | insert it into the sorted portion, 87 | 88 | 20 89 | 00:00:57,770 --> 00:01:01,209 90 | by shifting the required number 91 | of elements out of the way. 92 | 93 | 21 94 | 00:01:01,209 --> 00:01:03,750 95 | Hopefully this visualization 96 | will help you see exactly what's 97 | 98 | 22 99 | 00:01:03,750 --> 00:01:05,980 100 | going on with insertion sort. 101 | 102 | 23 103 | 00:01:05,980 --> 00:01:08,010 104 | >> So again, here's our 105 | entire unsorted array, 106 | 107 | 24 108 | 00:01:08,010 --> 00:01:10,970 109 | all of the elements indicated in red. 110 | 111 | 25 112 | 00:01:10,970 --> 00:01:13,320 113 | And let's follow the 114 | steps of our pseudocode. 115 | 116 | 26 117 | 00:01:13,320 --> 00:01:16,970 118 | The first thing we do, is we call the 119 | first element of the array, sorted. 120 | 121 | 27 122 | 00:01:16,970 --> 00:01:20,920 123 | So we're just gonna say 124 | five, you're now sorted. 125 | 126 | 28 127 | 00:01:20,920 --> 00:01:24,570 128 | >> Then we look at the next 129 | unsorted element of the array 130 | 131 | 29 132 | 00:01:24,570 --> 00:01:27,610 133 | and we want to insert that 134 | into the sorted portion, 135 | 136 | 30 137 | 00:01:27,610 --> 00:01:29,750 138 | by shifting elements over. 139 | 140 | 31 141 | 00:01:29,750 --> 00:01:33,470 142 | So two is the next unsorted 143 | element of the array. 144 | 145 | 32 146 | 00:01:33,470 --> 00:01:36,250 147 | Clearly it belongs before the 148 | five, so what we're gonna do 149 | 150 | 33 151 | 00:01:36,250 --> 00:01:41,580 152 | is sort of hold two aside for a second, 153 | shift five over, and then insert two 154 | 155 | 34 156 | 00:01:41,580 --> 00:01:43,210 157 | before five, where to should go. 158 | 159 | 35 160 | 00:01:43,210 --> 00:01:45,280 161 | And now we can say that two is sorted. 162 | 163 | 36 164 | 00:01:45,280 --> 00:01:48,400 165 | >> So as you can see, we've only so far 166 | looked at two elements of the array. 167 | 168 | 37 169 | 00:01:48,400 --> 00:01:50,600 170 | We haven't looked at the 171 | rest at all, but we've 172 | 173 | 38 174 | 00:01:50,600 --> 00:01:54,582 175 | got those two elements sorted by 176 | way of the shifting mechanism. 177 | 178 | 39 179 | 00:01:54,582 --> 00:01:56,410 180 | >> So we repeat the process again. 181 | 182 | 40 183 | 00:01:56,410 --> 00:01:58,850 184 | Look at the next unsorted 185 | element, that's one. 186 | 187 | 41 188 | 00:01:58,850 --> 00:02:04,010 189 | Let's hold that aside for a second, 190 | shift everything over, and put one 191 | 192 | 42 193 | 00:02:04,010 --> 00:02:05,570 194 | where it should go. 195 | 196 | 43 197 | 00:02:05,570 --> 00:02:08,110 198 | >> Again, still, we've only ever 199 | looked at one, two, and five. 200 | 201 | 44 202 | 00:02:08,110 --> 00:02:12,480 203 | We don't know what else is coming, 204 | but we've sorted those three elements. 205 | 206 | 45 207 | 00:02:12,480 --> 00:02:16,030 208 | >> Next unsorted element is 209 | three, so we'll set it aside. 210 | 211 | 46 212 | 00:02:16,030 --> 00:02:18,200 213 | We'll shift over what we 214 | need to which, this time 215 | 216 | 47 217 | 00:02:18,200 --> 00:02:21,820 218 | is not everything as in the previous 219 | two cases, it's just the five. 220 | 221 | 48 222 | 00:02:21,820 --> 00:02:25,440 223 | And then we'll stick three in, 224 | between the two and the five. 225 | 226 | 49 227 | 00:02:25,440 --> 00:02:27,849 228 | >> Six is the next unsorted 229 | element to the array. 230 | 231 | 50 232 | 00:02:27,849 --> 00:02:31,140 233 | And in fact six is greater than five, so 234 | we don't even need to do any swapping. 235 | 236 | 51 237 | 00:02:31,140 --> 00:02:35,710 238 | We can just tack six right on to 239 | the end of the sorted portion. 240 | 241 | 52 242 | 00:02:35,710 --> 00:02:38,270 243 | >> Lastly, four is the 244 | last unsorted element. 245 | 246 | 53 247 | 00:02:38,270 --> 00:02:42,060 248 | So we'll set it aside, shift over 249 | the elements we need to shift over, 250 | 251 | 54 252 | 00:02:42,060 --> 00:02:43,780 253 | and then put four where it belongs. 254 | 255 | 55 256 | 00:02:43,780 --> 00:02:46,400 257 | And now look, we've sort 258 | of all the elements. 259 | 260 | 56 261 | 00:02:46,400 --> 00:02:48,150 262 | Notice with insertion 263 | sort, we didn't have 264 | 265 | 57 266 | 00:02:48,150 --> 00:02:50,240 267 | to go back and forth across the array. 268 | 269 | 58 270 | 00:02:50,240 --> 00:02:54,720 271 | We only went across the array 272 | one time, and we shifted things 273 | 274 | 59 275 | 00:02:54,720 --> 00:02:59,870 276 | that we'd already encountered, in order 277 | to make room for the new elements. 278 | 279 | 60 280 | 00:02:59,870 --> 00:03:02,820 281 | >> So what's the worst case 282 | scenario with insertion sort? 283 | 284 | 61 285 | 00:03:02,820 --> 00:03:05,090 286 | In the worst case, the 287 | array is in reverse order. 288 | 289 | 62 290 | 00:03:05,090 --> 00:03:11,180 291 | You have to shift each of the n elements 292 | up to n positions, every single time we 293 | 294 | 63 295 | 00:03:11,180 --> 00:03:12,880 296 | make an insertion. 297 | 298 | 64 299 | 00:03:12,880 --> 00:03:15,720 300 | That's a lot of shifting. 301 | 302 | 65 303 | 00:03:15,720 --> 00:03:18,014 304 | >> In the best case, the 305 | array is perfectly sorted. 306 | 307 | 66 308 | 00:03:18,014 --> 00:03:20,680 309 | And sort of like what happened 310 | with five and six in the example, 311 | 312 | 67 313 | 00:03:20,680 --> 00:03:23,779 314 | where we could just tack it on 315 | without having to do any shifting, 316 | 317 | 68 318 | 00:03:23,779 --> 00:03:24,820 319 | we'd essentially do that. 320 | 321 | 69 322 | 00:03:24,820 --> 00:03:27,560 323 | >> If you imagine that our 324 | array was one through six, 325 | 326 | 70 327 | 00:03:27,560 --> 00:03:29,900 328 | we'd start off by 329 | declaring one is sorted. 330 | 331 | 71 332 | 00:03:29,900 --> 00:03:33,300 333 | Two comes after one so we can just 334 | say, OK, well one and two are sorted. 335 | 336 | 72 337 | 00:03:33,300 --> 00:03:36,190 338 | Three comes after two so, OK, 339 | one and two and three are sorted. 340 | 341 | 73 342 | 00:03:36,190 --> 00:03:39,590 343 | >> We're not making any swaps, we're 344 | just moving this arbitrary line 345 | 346 | 74 347 | 00:03:39,590 --> 00:03:42,460 348 | between sorted and unsorted as we go. 349 | 350 | 75 351 | 00:03:42,460 --> 00:03:46,646 352 | As effectively as we did in the example, 353 | turning elements blue, as we proceed. 354 | 355 | 76 356 | 00:03:46,646 --> 00:03:48,270 357 | So what's the worst case runtime, then? 358 | 359 | 77 360 | 00:03:48,270 --> 00:03:51,854 361 | Remember, if we have to shift each of 362 | the n elements possibly n positions, 363 | 364 | 78 365 | 00:03:51,854 --> 00:03:54,020 366 | hopefully that gives you 367 | an idea that the worst case 368 | 369 | 79 370 | 00:03:54,020 --> 00:03:57,770 371 | runtime is Big O of n squared. 372 | 373 | 80 374 | 00:03:57,770 --> 00:04:00,220 375 | >> If the array is perfectly 376 | sorted, all we have to do 377 | 378 | 81 379 | 00:04:00,220 --> 00:04:04,480 380 | is look at every single element 381 | once, and then we're done. 382 | 383 | 82 384 | 00:04:04,480 --> 00:04:08,440 385 | So in the best case, it's omega of n. 386 | 387 | 83 388 | 00:04:08,440 --> 00:04:09,490 389 | >> I'm Doug Lloyd. 390 | 391 | 84 392 | 00:04:09,490 --> 00:04:11,760 393 | This is CS50. 394 | 395 | 85 396 | 00:04:11,760 --> 00:04:13,119 397 | -------------------------------------------------------------------------------- /2015/en/sections/introduction_to_ai.srt: -------------------------------------------------------------------------------- 1 | 1 2 | 00:00:00,000 --> 00:00:00,131 3 | 4 | 2 5 | 00:00:00,131 --> 00:00:03,130 6 | BRIAN SCASSELLATI: One of the really 7 | great things about computer science 8 | 9 | 3 10 | 00:00:03,130 --> 00:00:06,500 11 | is that, with even only 12 | a few weeks of study, 13 | 14 | 4 15 | 00:00:06,500 --> 00:00:10,450 16 | you're able to understand some of the 17 | software and the intelligent structures 18 | 19 | 5 20 | 00:00:10,450 --> 00:00:13,240 21 | that are all around us 22 | in the modern world. 23 | 24 | 6 25 | 00:00:13,240 --> 00:00:16,129 26 | In this short video series, we're 27 | going to be talking about some 28 | 29 | 7 30 | 00:00:16,129 --> 00:00:19,210 31 | of these different tools 32 | that are out there. 33 | 34 | 8 35 | 00:00:19,210 --> 00:00:23,370 36 | We'll talk about things like how Netflix 37 | is able to suggest movies for you 38 | 39 | 9 40 | 00:00:23,370 --> 00:00:27,490 41 | that you might like, how Facebook 42 | is able to tag photos of you 43 | 44 | 10 45 | 00:00:27,490 --> 00:00:31,190 46 | with your name, how Siri is 47 | able to answer your questions, 48 | 49 | 11 50 | 00:00:31,190 --> 00:00:35,390 51 | or how at Google an autonomous 52 | car is able to drive on the roads. 53 | 54 | 12 55 | 00:00:35,390 --> 00:00:37,820 56 | >> You'll find that each of 57 | these different systems 58 | 59 | 13 60 | 00:00:37,820 --> 00:00:41,600 61 | runs on basic concepts that 62 | map back to the concepts 63 | 64 | 14 65 | 00:00:41,600 --> 00:00:43,590 66 | that we've talked about in class. 67 | 68 | 15 69 | 00:00:43,590 --> 00:00:47,030 70 | So I hope you'll join 71 | me, watch these videos, 72 | 73 | 16 74 | 00:00:47,030 --> 00:00:50,830 75 | and see that the things that 76 | you studied here actually 77 | 78 | 17 79 | 00:00:50,830 --> 00:00:55,390 80 | give you a great amount of leverage on 81 | the structures in the world around you. 82 | 83 | 18 84 | 00:00:55,390 --> 00:00:59,330 85 | I think you'll be surprised 86 | by just how much you know. 87 | 88 | 19 89 | 00:00:59,330 --> 00:01:00,556 90 | -------------------------------------------------------------------------------- /2015/en/sections/linear_search.srt: -------------------------------------------------------------------------------- 1 | 1 2 | 00:00:00,000 --> 00:00:02,892 3 | >> [MUSIC PLAYING] 4 | 5 | 2 6 | 00:00:02,892 --> 00:00:05,347 7 | 8 | 3 9 | 00:00:05,347 --> 00:00:07,180 10 | DOUG LLOYD: Linear 11 | search is an algorithm we 12 | 13 | 4 14 | 00:00:07,180 --> 00:00:09,840 15 | can use to find an element in an array. 16 | 17 | 5 18 | 00:00:09,840 --> 00:00:11,990 19 | An algorithm recall 20 | is a step-by-step set 21 | 22 | 6 23 | 00:00:11,990 --> 00:00:15,030 24 | of instructions for completing a task. 25 | 26 | 7 27 | 00:00:15,030 --> 00:00:17,480 28 | >> The linear search 29 | algorithm works as follows. 30 | 31 | 8 32 | 00:00:17,480 --> 00:00:22,200 33 | Iterate across the array from left to 34 | right, looking for a specified element. 35 | 36 | 9 37 | 00:00:22,200 --> 00:00:26,380 38 | >> In pseudocode, which is a more 39 | distilled version of this sentence, 40 | 41 | 10 42 | 00:00:26,380 --> 00:00:29,840 43 | if the first element is what 44 | you're looking for, you can stop. 45 | 46 | 11 47 | 00:00:29,840 --> 00:00:33,930 48 | Otherwise, move to the next element and 49 | keep going over and over until you find 50 | 51 | 12 52 | 00:00:33,930 --> 00:00:36,389 53 | the element, or you don't. 54 | 55 | 13 56 | 00:00:36,389 --> 00:00:38,680 57 | So we can use the linear 58 | search algorithm, for example, 59 | 60 | 14 61 | 00:00:38,680 --> 00:00:42,330 62 | to find the target value 63 | nine in this array. 64 | 65 | 15 66 | 00:00:42,330 --> 00:00:43,870 67 | Well we start at the beginning. 68 | 69 | 16 70 | 00:00:43,870 --> 00:00:45,970 71 | If it's what we're 72 | looking for, we can stop. 73 | 74 | 17 75 | 00:00:45,970 --> 00:00:47,890 76 | It's not, we're not looking for 11. 77 | 78 | 18 79 | 00:00:47,890 --> 00:00:50,220 80 | So otherwise, move to the next element. 81 | 82 | 19 83 | 00:00:50,220 --> 00:00:51,510 84 | >> So we look at 23. 85 | 86 | 20 87 | 00:00:51,510 --> 00:00:52,730 88 | Is 23 what we're looking for? 89 | 90 | 21 91 | 00:00:52,730 --> 00:00:55,614 92 | Well no, so we move on to the next 93 | element, and the next element, 94 | 95 | 22 96 | 00:00:55,614 --> 00:00:57,780 97 | and we keep going through 98 | this process over and over 99 | 100 | 23 101 | 00:00:57,780 --> 00:01:01,030 102 | and over, until we land 103 | on a situation like this. 104 | 105 | 24 106 | 00:01:01,030 --> 00:01:03,910 107 | >> Nine is what we're looking for, 108 | and this element of the array 109 | 110 | 25 111 | 00:01:03,910 --> 00:01:05,787 112 | is, it's value is nine. 113 | 114 | 26 115 | 00:01:05,787 --> 00:01:08,120 116 | And so we found what we're 117 | looking for, and we can stop. 118 | 119 | 27 120 | 00:01:08,120 --> 00:01:11,910 121 | The linear search has 122 | completed, successfully. 123 | 124 | 28 125 | 00:01:11,910 --> 00:01:15,370 126 | >> But what about if we're looking for 127 | an element that's not in our array. 128 | 129 | 29 130 | 00:01:15,370 --> 00:01:17,040 131 | Does linear search still work? 132 | 133 | 30 134 | 00:01:17,040 --> 00:01:17,540 135 | Well sure. 136 | 137 | 31 138 | 00:01:17,540 --> 00:01:19,947 139 | So we repeat this process 140 | starting at the first element. 141 | 142 | 32 143 | 00:01:19,947 --> 00:01:21,780 144 | If it's what we're 145 | looking for, we can stop. 146 | 147 | 33 148 | 00:01:21,780 --> 00:01:22,800 149 | It's not. 150 | 151 | 34 152 | 00:01:22,800 --> 00:01:25,020 153 | Otherwise, we move to the next element. 154 | 155 | 35 156 | 00:01:25,020 --> 00:01:29,050 157 | >> But we can keep repeating this process, 158 | examining each element in turn, 159 | 160 | 36 161 | 00:01:29,050 --> 00:01:31,720 162 | hoping that we find the number 50. 163 | 164 | 37 165 | 00:01:31,720 --> 00:01:33,750 166 | But we won't know if 167 | we've found the number 50 168 | 169 | 38 170 | 00:01:33,750 --> 00:01:38,290 171 | or if we didn't, until we've stepped 172 | over every single element of the array. 173 | 174 | 39 175 | 00:01:38,290 --> 00:01:40,440 176 | >> Only once we've done 177 | that and come up short, 178 | 179 | 40 180 | 00:01:40,440 --> 00:01:43,040 181 | can we conclude that 182 | 50 is not in the array. 183 | 184 | 41 185 | 00:01:43,040 --> 00:01:46,410 186 | And so the linear search 187 | algorithm, well it failed, per se. 188 | 189 | 42 190 | 00:01:46,410 --> 00:01:49,181 191 | But not in the sense that it 192 | was unsuccessful in doing what 193 | 194 | 43 195 | 00:01:49,181 --> 00:01:49,930 196 | we asked it to do. 197 | 198 | 44 199 | 00:01:49,930 --> 00:01:52,390 200 | >> It was unsuccessful in as 201 | much as it didn't find 50, 202 | 203 | 45 204 | 00:01:52,390 --> 00:01:54,070 205 | but 50 wasn't in the array. 206 | 207 | 46 208 | 00:01:54,070 --> 00:01:57,310 209 | But we have exhaustively searched 210 | through every single element 211 | 212 | 47 213 | 00:01:57,310 --> 00:02:00,550 214 | and so, while we didn't find 215 | anything, linear search still 216 | 217 | 48 218 | 00:02:00,550 --> 00:02:05,230 219 | succeeds even if the 220 | element is not in the array. 221 | 222 | 49 223 | 00:02:05,230 --> 00:02:07,507 224 | >> So what's the worst case 225 | scenario with linear search? 226 | 227 | 50 228 | 00:02:07,507 --> 00:02:09,590 229 | Well we have to look through 230 | every single element, 231 | 232 | 51 233 | 00:02:09,590 --> 00:02:14,590 234 | either because the target element 235 | is the last element of the array, 236 | 237 | 52 238 | 00:02:14,590 --> 00:02:18,510 239 | or the element we're looking for doesn't 240 | actually exist in the array at all. 241 | 242 | 53 243 | 00:02:18,510 --> 00:02:19,760 244 | What's the best case scenario? 245 | 246 | 54 247 | 00:02:19,760 --> 00:02:22,430 248 | Well we might find the 249 | element immediately. 250 | 251 | 55 252 | 00:02:22,430 --> 00:02:24,360 253 | And how many elements 254 | do we then have to look 255 | 256 | 56 257 | 00:02:24,360 --> 00:02:26,859 258 | at in the best case, 259 | if we're looking for it 260 | 261 | 57 262 | 00:02:26,859 --> 00:02:28,400 263 | and we find it at the very beginning? 264 | 265 | 58 266 | 00:02:28,400 --> 00:02:29,850 267 | We can stop immediately. 268 | 269 | 59 270 | 00:02:29,850 --> 00:02:32,984 271 | >> What does this say about the 272 | complexity of linear search? 273 | 274 | 60 275 | 00:02:32,984 --> 00:02:35,650 276 | Well in the worst case, we have 277 | to look at every single element. 278 | 279 | 61 280 | 00:02:35,650 --> 00:02:38,930 281 | And so it runs in O of 282 | n, in the worst case. 283 | 284 | 62 285 | 00:02:38,930 --> 00:02:41,540 286 | >> In the best case, we're gonna 287 | find the element immediately. 288 | 289 | 63 290 | 00:02:41,540 --> 00:02:44,750 291 | And so runs in omega of 1. 292 | 293 | 64 294 | 00:02:44,750 --> 00:02:45,780 295 | >> I'm Doug Lloyd. 296 | 297 | 65 298 | 00:02:45,780 --> 00:02:48,020 299 | This is CS50. 300 | 301 | 66 302 | 00:02:48,020 --> 00:02:49,876 303 | -------------------------------------------------------------------------------- /2015/en/sections/selection_sort.srt: -------------------------------------------------------------------------------- 1 | 1 2 | 00:00:00,000 --> 00:00:05,726 3 | >> [MUSIC PLAYING] 4 | 5 | 2 6 | 00:00:05,726 --> 00:00:08,600 7 | DOUG LLOYD: Selection sort is an 8 | algorithm that, as you might expect, 9 | 10 | 3 11 | 00:00:08,600 --> 00:00:10,470 12 | sorts a set of elements. 13 | 14 | 4 15 | 00:00:10,470 --> 00:00:12,470 16 | And algorithm recall 17 | is a step-by-step set 18 | 19 | 5 20 | 00:00:12,470 --> 00:00:15,260 21 | of instructions for completing a task. 22 | 23 | 6 24 | 00:00:15,260 --> 00:00:17,580 25 | >> In selection sort the 26 | basic idea is this, 27 | 28 | 7 29 | 00:00:17,580 --> 00:00:22,080 30 | find the smallest unsorted element and 31 | add it to the end of the sorted list. 32 | 33 | 8 34 | 00:00:22,080 --> 00:00:26,970 35 | Effectively what this does is build 36 | a sorted list, one element at a time. 37 | 38 | 9 39 | 00:00:26,970 --> 00:00:29,800 40 | Breaking it down to pseudocode 41 | we could state this algorithm 42 | 43 | 10 44 | 00:00:29,800 --> 00:00:34,490 45 | as follows, repeat this until 46 | no unsorted elements remain. 47 | 48 | 11 49 | 00:00:34,490 --> 00:00:38,660 50 | Search through the unsorted 51 | data to find the smallest value, 52 | 53 | 12 54 | 00:00:38,660 --> 00:00:44,130 55 | then swap the smallest value with the 56 | first element of the unsorted part. 57 | 58 | 13 59 | 00:00:44,130 --> 00:00:47,130 60 | >> It may help to visualize this, 61 | so let's take a look at this. 62 | 63 | 14 64 | 00:00:47,130 --> 00:00:49,710 65 | So this, I contend, is an 66 | unsorted array and I've 67 | 68 | 15 69 | 00:00:49,710 --> 00:00:53,040 70 | indicated it by indicating that all 71 | of the elements are colored red, 72 | 73 | 16 74 | 00:00:53,040 --> 00:00:54,420 75 | they are not yet sorted. 76 | 77 | 17 78 | 00:00:54,420 --> 00:00:57,670 79 | This is the entire 80 | unsorted part of the array. 81 | 82 | 18 83 | 00:00:57,670 --> 00:01:02,020 84 | >> So let's go through the steps of 85 | selection sort to sort this array. 86 | 87 | 19 88 | 00:01:02,020 --> 00:01:05,296 89 | So again, we're gonna repeat 90 | until no unsorted elements remain. 91 | 92 | 20 93 | 00:01:05,296 --> 00:01:07,920 94 | We're gonna search through the 95 | data to find the smallest value, 96 | 97 | 21 98 | 00:01:07,920 --> 00:01:11,990 99 | and then swap that value with the 100 | first element of the unsorted part. 101 | 102 | 22 103 | 00:01:11,990 --> 00:01:14,380 104 | >> Right now, again, the entire 105 | array is the unsorted part. 106 | 107 | 23 108 | 00:01:14,380 --> 00:01:16,534 109 | All of the red elements are unsorted. 110 | 111 | 24 112 | 00:01:16,534 --> 00:01:18,700 113 | So we search through and 114 | we find the smallest value. 115 | 116 | 25 117 | 00:01:18,700 --> 00:01:20,533 118 | We start at the beginning, 119 | we go to the end, 120 | 121 | 26 122 | 00:01:20,533 --> 00:01:23,630 123 | we find the smallest value is, one. 124 | 125 | 27 126 | 00:01:23,630 --> 00:01:24,860 127 | So that's part one. 128 | 129 | 28 130 | 00:01:24,860 --> 00:01:29,440 131 | And then part two, swap that value with 132 | the first element of the unsorted part, 133 | 134 | 29 135 | 00:01:29,440 --> 00:01:31,340 136 | or the first red element. 137 | 138 | 30 139 | 00:01:31,340 --> 00:01:34,980 140 | >> In this case that would be 141 | five, so we swap one and five. 142 | 143 | 31 144 | 00:01:34,980 --> 00:01:37,320 145 | When we do this, we can 146 | visually see that we've 147 | 148 | 32 149 | 00:01:37,320 --> 00:01:41,260 150 | moved the smallest valued element 151 | of the array, to the very beginning. 152 | 153 | 33 154 | 00:01:41,260 --> 00:01:43,920 155 | Effectively sorting that element. 156 | 157 | 34 158 | 00:01:43,920 --> 00:01:47,520 159 | >> And so we can indeed confirm 160 | and state that one, is sorted. 161 | 162 | 35 163 | 00:01:47,520 --> 00:01:52,080 164 | And so we'll indicate the sorted portion 165 | of our array, by coloring it blue. 166 | 167 | 36 168 | 00:01:52,080 --> 00:01:53,860 169 | >> Now we just repeat the process again. 170 | 171 | 37 172 | 00:01:53,860 --> 00:01:57,430 173 | We search through the unsorted part of 174 | the array to find the smallest element. 175 | 176 | 38 177 | 00:01:57,430 --> 00:01:59,000 178 | In this case, it's two. 179 | 180 | 39 181 | 00:01:59,000 --> 00:02:02,100 182 | >> We swap that with the first 183 | element of the unsorted part. 184 | 185 | 40 186 | 00:02:02,100 --> 00:02:05,540 187 | In this case two also happens to be 188 | the first element of the unsorted part. 189 | 190 | 41 191 | 00:02:05,540 --> 00:02:08,650 192 | So we swap two with itself, 193 | which really just leaves two 194 | 195 | 42 196 | 00:02:08,650 --> 00:02:11,257 197 | where it is, and it's sorted. 198 | 199 | 43 200 | 00:02:11,257 --> 00:02:13,840 201 | Continuing on, we search through 202 | to find the smallest element. 203 | 204 | 44 205 | 00:02:13,840 --> 00:02:15,030 206 | It's three. 207 | 208 | 45 209 | 00:02:15,030 --> 00:02:17,650 210 | We swap it with the first 211 | element, which is five. 212 | 213 | 46 214 | 00:02:17,650 --> 00:02:19,450 215 | And now three is sorted. 216 | 217 | 47 218 | 00:02:19,450 --> 00:02:22,440 219 | >> We search through again, and we 220 | find the smallest element is four. 221 | 222 | 48 223 | 00:02:22,440 --> 00:02:28,070 224 | We swap it with the first element of the 225 | unsorted part, and now four is sorted. 226 | 227 | 49 228 | 00:02:28,070 --> 00:02:29,910 229 | >> We find that five is 230 | the smallest element. 231 | 232 | 50 233 | 00:02:29,910 --> 00:02:32,900 234 | We swap it with the first 235 | element of the unsorted part. 236 | 237 | 51 238 | 00:02:32,900 --> 00:02:34,740 239 | And now five is sorted. 240 | 241 | 52 242 | 00:02:34,740 --> 00:02:36,660 243 | >> And then lastly, our 244 | unsorted part consists 245 | 246 | 53 247 | 00:02:36,660 --> 00:02:38,576 248 | of just a single element, 249 | so we search through 250 | 251 | 54 252 | 00:02:38,576 --> 00:02:41,740 253 | and we find that six is the 254 | smallest, and in fact, only element. 255 | 256 | 55 257 | 00:02:41,740 --> 00:02:44,906 258 | And then we can state that it is sorted. 259 | 260 | 56 261 | 00:02:44,906 --> 00:02:47,530 262 | And now we've switched our array 263 | from being completely unsorted 264 | 265 | 57 266 | 00:02:47,530 --> 00:02:52,660 267 | in red, to completely sorted 268 | in blue, using selection sort. 269 | 270 | 58 271 | 00:02:52,660 --> 00:02:54,920 272 | >> So what's the worst case scenario here? 273 | 274 | 59 275 | 00:02:54,920 --> 00:02:57,830 276 | Well in the absolute worst 277 | case, we have to look over 278 | 279 | 60 280 | 00:02:57,830 --> 00:03:02,170 281 | all of the elements of the array to 282 | find the smallest unsorted element, 283 | 284 | 61 285 | 00:03:02,170 --> 00:03:04,750 286 | and we have to repeat 287 | this process n times. 288 | 289 | 62 290 | 00:03:04,750 --> 00:03:09,090 291 | Once for each element of the array 292 | because we only, in this algorithm, 293 | 294 | 63 295 | 00:03:09,090 --> 00:03:12,180 296 | sort one element at time. 297 | 298 | 64 299 | 00:03:12,180 --> 00:03:13,595 300 | >> What's the best case scenario? 301 | 302 | 65 303 | 00:03:13,595 --> 00:03:15,040 304 | Well it's exactly the same, right? 305 | 306 | 66 307 | 00:03:15,040 --> 00:03:18,440 308 | We actually have to still step through 309 | every single element of the array 310 | 311 | 67 312 | 00:03:18,440 --> 00:03:22,040 313 | in order to confirm that it is, 314 | in fact, the smallest element. 315 | 316 | 68 317 | 00:03:22,040 --> 00:03:26,760 318 | >> So the worst case runtime, we 319 | have to repeat a process n times, 320 | 321 | 69 322 | 00:03:26,760 --> 00:03:28,960 323 | once for each of n elements. 324 | 325 | 70 326 | 00:03:28,960 --> 00:03:31,940 327 | And in the best case scenario, 328 | we have to do the same. 329 | 330 | 71 331 | 00:03:31,940 --> 00:03:35,340 332 | >> So thinking back to our 333 | computational complexity toolbox, 334 | 335 | 72 336 | 00:03:35,340 --> 00:03:39,250 337 | what do you think is the worst 338 | case runtime for selection sort? 339 | 340 | 73 341 | 00:03:39,250 --> 00:03:41,840 342 | What do you think is the best 343 | case runtime for selection sort? 344 | 345 | 74 346 | 00:03:41,840 --> 00:03:44,760 347 | 348 | 75 349 | 00:03:44,760 --> 00:03:49,325 350 | >> Did you guess Big O of n squared, 351 | and Big Omega of n squared? 352 | 353 | 76 354 | 00:03:49,325 --> 00:03:49,950 355 | You'd be right. 356 | 357 | 77 358 | 00:03:49,950 --> 00:03:52,490 359 | Those are, in fact, the 360 | worst case and best case run 361 | 362 | 78 363 | 00:03:52,490 --> 00:03:55,100 364 | times, for selection sort. 365 | 366 | 79 367 | 00:03:55,100 --> 00:03:56,260 368 | >> I'm Doug Lloyd. 369 | 370 | 80 371 | 00:03:56,260 --> 00:03:58,600 372 | This is CS50. 373 | 374 | 81 375 | 00:03:58,600 --> 00:04:00,279 376 | -------------------------------------------------------------------------------- /2015/en/seminars/server_01.srt: -------------------------------------------------------------------------------- 1 | 1 2 | 00:00:00,000 --> 00:00:00,160 3 | 4 | 2 5 | 00:00:00,160 --> 00:00:02,660 6 | >> SPEAKER 1: All right, let's take a 7 | look at how the staff solution actually 8 | 9 | 3 10 | 00:00:02,660 --> 00:00:04,760 11 | operates, so that you 12 | get a sense, first off 13 | 14 | 4 15 | 00:00:04,760 --> 00:00:06,930 16 | how the web server's supposed 17 | to run, and how you can actually 18 | 19 | 5 20 | 00:00:06,930 --> 00:00:08,480 21 | get it running on your own computer. 22 | 23 | 6 24 | 00:00:08,480 --> 00:00:09,350 25 | So picture it here. 26 | 27 | 7 28 | 00:00:09,350 --> 00:00:13,640 29 | I've already installed in CS50 ID 30 | pset6 dot zip, per the specification. 31 | 32 | 8 33 | 00:00:13,640 --> 00:00:16,197 34 | I've unzipped it, and I've 35 | CDed into my pset6 directory. 36 | 37 | 9 38 | 00:00:16,197 --> 00:00:18,780 39 | One of the first things you're 40 | going to want to do, especially 41 | 42 | 10 43 | 00:00:18,780 --> 00:00:22,010 44 | if you've been using a CS50 IDE to play 45 | along with recent lectures, wherein 46 | 47 | 11 48 | 00:00:22,010 --> 00:00:25,640 49 | we've been using PHP in 50 | CS50 IDE, specifically, 51 | 52 | 12 53 | 00:00:25,640 --> 00:00:29,050 54 | using that web server called Apache, 55 | whereby you can start and stop it 56 | 57 | 13 58 | 00:00:29,050 --> 00:00:30,910 59 | with that command, Apache 50. 60 | 61 | 14 62 | 00:00:30,910 --> 00:00:34,160 63 | First, go ahead and 64 | type "Apache 50 stop" 65 | 66 | 15 67 | 00:00:34,160 --> 00:00:37,370 68 | just to make sure that if you were 69 | following along in recent days, 70 | 71 | 16 72 | 00:00:37,370 --> 00:00:40,090 73 | and you turned on Apache, you're 74 | turning it off in this way 75 | 76 | 17 77 | 00:00:40,090 --> 00:00:41,360 78 | by stopping the server. 79 | 80 | 18 81 | 00:00:41,360 --> 00:00:44,110 82 | Now, what I'm going to do is exactly 83 | what the spec tells me to do. 84 | 85 | 19 86 | 00:00:44,110 --> 00:00:49,770 87 | I'm going to go to tilda CS50 slash 88 | pset6 slash server, and just hit Enter. 89 | 90 | 20 91 | 00:00:49,770 --> 00:00:52,840 92 | You'll notice that I'm yelled at 93 | with some usage information, whereby 94 | 95 | 21 96 | 00:00:52,840 --> 00:00:54,960 97 | I should be running 98 | the program as server 99 | 100 | 22 101 | 00:00:54,960 --> 00:00:58,230 102 | with an optional dash p and then a 103 | port number, which you can actually 104 | 105 | 23 106 | 00:00:58,230 --> 00:01:00,720 107 | leave blank because by 108 | default, per the spec, 109 | 110 | 24 111 | 00:01:00,720 --> 00:01:04,010 112 | the web server is going to 113 | assume that you want port 8080. 114 | 115 | 25 116 | 00:01:04,010 --> 00:01:07,560 117 | Meanwhile, you might recall that 118 | port 8080 is not really standard, 119 | 120 | 26 121 | 00:01:07,560 --> 00:01:09,380 122 | rather port 80 is the 123 | number we've talked 124 | 125 | 27 126 | 00:01:09,380 --> 00:01:11,440 127 | about being the default for HTTP. 128 | 129 | 28 130 | 00:01:11,440 --> 00:01:14,870 131 | Well, turns out that CS50 IDE 132 | is simply configured in a way, 133 | 134 | 29 135 | 00:01:14,870 --> 00:01:18,730 136 | such that when you with a browser try 137 | to visit port 80 from the outside world, 138 | 139 | 30 140 | 00:01:18,730 --> 00:01:22,210 141 | it's going to sort of magically 142 | port forward, or redirect itself, 143 | 144 | 31 145 | 00:01:22,210 --> 00:01:25,200 146 | to port 8080 inside 147 | of your server itself. 148 | 149 | 32 150 | 00:01:25,200 --> 00:01:29,330 151 | >> So the last thing here is the command 152 | line argument, the path to route. 153 | 154 | 33 155 | 00:01:29,330 --> 00:01:31,590 156 | And by that I just 157 | mean, what folder do I 158 | 159 | 34 160 | 00:01:31,590 --> 00:01:34,820 161 | want to tell the server 162 | to use to serve up files? 163 | 164 | 35 165 | 00:01:34,820 --> 00:01:39,030 166 | In other words, if the user visits 167 | slash, what should he or she see? 168 | 169 | 36 170 | 00:01:39,030 --> 00:01:41,030 171 | Well, let's go ahead and 172 | run exactly that again, 173 | 174 | 37 175 | 00:01:41,030 --> 00:01:43,940 176 | this time specifying that I 177 | want the root of my web server 178 | 179 | 38 180 | 00:01:43,940 --> 00:01:48,210 181 | to be the public directory, that comes 182 | with problem set six distribution code. 183 | 184 | 39 185 | 00:01:48,210 --> 00:01:50,620 186 | When I hit Enter, you'll see 187 | in yellow here, a reminder 188 | 189 | 40 190 | 00:01:50,620 --> 00:01:52,260 191 | as to what folder I'm actually using. 192 | 193 | 41 194 | 00:01:52,260 --> 00:01:55,870 195 | In this case, it's a long string, 196 | "home ubuntu workspace pset6 public." 197 | 198 | 42 199 | 00:01:55,870 --> 00:01:57,500 200 | And that last word is what's key. 201 | 202 | 43 203 | 00:01:57,500 --> 00:02:01,180 204 | And then lastly, apparently, my 205 | server's now listening on port 8080. 206 | 207 | 44 208 | 00:02:01,180 --> 00:02:05,860 209 | >> What I'm next going to do is recall that 210 | in CS50 ID in the top right hand corner 211 | 212 | 45 213 | 00:02:05,860 --> 00:02:09,440 214 | of your screen, you're going to see 215 | a URL that is ide50-username.cs50.io. 216 | 217 | 46 218 | 00:02:09,440 --> 00:02:12,860 219 | 220 | 47 221 | 00:02:12,860 --> 00:02:15,080 222 | And indeed, if you click 223 | that, you'll be whisked away 224 | 225 | 48 226 | 00:02:15,080 --> 00:02:17,090 227 | to another browser tab, 228 | that, in this case, 229 | 230 | 49 231 | 00:02:17,090 --> 00:02:20,830 232 | is going to show me the contents 233 | of my web servers roots. 234 | 235 | 50 236 | 00:02:20,830 --> 00:02:24,770 237 | In other words, the files you see here, 238 | cat dot HTML, cat dot JPEG, favicon dot 239 | 240 | 51 241 | 00:02:24,770 --> 00:02:27,690 242 | ico, hello dot HTML, 243 | hello dot php, and test, 244 | 245 | 52 246 | 00:02:27,690 --> 00:02:29,800 247 | are all of the same 248 | contents that you would see 249 | 250 | 53 251 | 00:02:29,800 --> 00:02:32,560 252 | with LS inside of my public directory. 253 | 254 | 54 255 | 00:02:32,560 --> 00:02:36,790 256 | And what's nice is that if I go 257 | ahead and click now on cat dot HTML, 258 | 259 | 55 260 | 00:02:36,790 --> 00:02:38,710 261 | I see cat dot HTML. 262 | 263 | 56 264 | 00:02:38,710 --> 00:02:42,660 265 | And if I click on cat dot 266 | JPEG, or hello dot HTML, 267 | 268 | 57 269 | 00:02:42,660 --> 00:02:46,650 270 | or even type in my name David, 271 | and then click "say hello," 272 | 273 | 58 274 | 00:02:46,650 --> 00:02:49,420 275 | you'll see that all of the 276 | files work because the staff 277 | 278 | 59 279 | 00:02:49,420 --> 00:02:52,820 280 | solution, of course, installed 281 | in CS50 ID is fully functional. 282 | 283 | 60 284 | 00:02:52,820 --> 00:02:57,090 285 | So it works exactly as your own 286 | solution should ultimately work. 287 | 288 | 61 289 | 00:02:57,090 --> 00:03:00,990 290 | >> Meanwhile, if we go back to my terminal 291 | window, where I ran the server command, 292 | 293 | 62 294 | 00:03:00,990 --> 00:03:03,410 295 | notice what the console has been saying. 296 | 297 | 63 298 | 00:03:03,410 --> 00:03:07,890 299 | I see here that the first request that 300 | I received was literally get slash cat 301 | 302 | 64 303 | 00:03:07,890 --> 00:03:10,260 304 | dot HTML, HTTP version 1.1. 305 | 306 | 65 307 | 00:03:10,260 --> 00:03:12,600 308 | And then, in green what 309 | the staff solution has done 310 | 311 | 66 312 | 00:03:12,600 --> 00:03:14,580 313 | is it's showing me the 314 | first line of output 315 | 316 | 67 317 | 00:03:14,580 --> 00:03:16,340 318 | that the web server is responding with. 319 | 320 | 68 321 | 00:03:16,340 --> 00:03:18,300 322 | In other words, we've 323 | already written the code 324 | 325 | 69 326 | 00:03:18,300 --> 00:03:21,530 327 | that opens up that virtual envelope, 328 | containing that get request. 329 | 330 | 70 331 | 00:03:21,530 --> 00:03:23,980 332 | And then we respond to the 333 | user but, simultaneously, 334 | 335 | 71 336 | 00:03:23,980 --> 00:03:28,780 337 | print to the output screen 338 | here HTTP 1.1, 200 OK 339 | 340 | 72 341 | 00:03:28,780 --> 00:03:31,900 342 | to confirm what we're putting in 343 | the return envelope, so to speak, 344 | 345 | 73 346 | 00:03:31,900 --> 00:03:33,540 347 | that we're sending back to the user. 348 | 349 | 74 350 | 00:03:33,540 --> 00:03:36,200 351 | >> And so what's going on here is 352 | that in the terminal window, 353 | 354 | 75 355 | 00:03:36,200 --> 00:03:38,510 356 | we're running the web 357 | server, and, therefore, it's 358 | 359 | 76 360 | 00:03:38,510 --> 00:03:42,480 361 | listening for HTTP 362 | requests on TCP port 8080. 363 | 364 | 77 365 | 00:03:42,480 --> 00:03:44,960 366 | Meanwhile, in my web browser, 367 | as I click through each 368 | 369 | 78 370 | 00:03:44,960 --> 00:03:48,480 371 | of those files, or even input my 372 | name David, and then click Submit, 373 | 374 | 79 375 | 00:03:48,480 --> 00:03:51,827 376 | that is my browser 377 | talking to the web server. 378 | 379 | 80 380 | 00:03:51,827 --> 00:03:54,410 381 | And what the web server's doing, 382 | then, in that terminal window 383 | 384 | 81 385 | 00:03:54,410 --> 00:03:56,370 386 | is showing me exactly 387 | the first line that's 388 | 389 | 82 390 | 00:03:56,370 --> 00:03:58,540 391 | been received in a virtual 392 | envelope and exactly 393 | 394 | 83 395 | 00:03:58,540 --> 00:04:02,870 396 | the first line that's being 397 | responded with to that web client. 398 | -------------------------------------------------------------------------------- /2015/en/seminars/server_03.srt: -------------------------------------------------------------------------------- 1 | 1 2 | 00:00:00,000 --> 00:00:00,200 3 | 4 | 2 5 | 00:00:00,200 --> 00:00:02,280 6 | >> SPEAKER 1: All right, so what 7 | is it you concretely need to do? 8 | 9 | 3 10 | 00:00:02,280 --> 00:00:04,140 11 | Well, turns out there's 12 | just four functions 13 | 14 | 4 15 | 00:00:04,140 --> 00:00:06,390 16 | that you need to implement 17 | whose functionality is 18 | 19 | 5 20 | 00:00:06,390 --> 00:00:08,520 21 | integral to the proper 22 | operation of the web server, 23 | 24 | 6 25 | 00:00:08,520 --> 00:00:10,720 26 | but all of whose 27 | behavior is very narrowly 28 | 29 | 7 30 | 00:00:10,720 --> 00:00:13,104 31 | defined, so that they only 32 | do pretty much one thing. 33 | 34 | 8 35 | 00:00:13,104 --> 00:00:15,270 36 | First thing you're going 37 | to need to do is implement, 38 | 39 | 9 40 | 00:00:15,270 --> 00:00:17,540 41 | per the specification, 42 | the LOOKUP function. 43 | 44 | 10 45 | 00:00:17,540 --> 00:00:20,900 46 | This is a fairly simple function in 47 | the end, that takes as an argument 48 | 49 | 11 50 | 00:00:20,900 --> 00:00:24,690 51 | whatever the path to the file 52 | that the user wants to request, 53 | 54 | 12 55 | 00:00:24,690 --> 00:00:28,310 56 | and you need to respond with the 57 | so-called MIME type, or Content-type, 58 | 59 | 13 60 | 00:00:28,310 --> 00:00:29,200 61 | of that file. 62 | 63 | 14 64 | 00:00:29,200 --> 00:00:31,415 65 | For instance, if it's 66 | a file like, hello dot 67 | 68 | 15 69 | 00:00:31,415 --> 00:00:37,470 70 | HTML you're going to respond with a MIME 71 | type of quote unquote text slash HTML. 72 | 73 | 16 74 | 00:00:37,470 --> 00:00:40,920 75 | >> Or if it's an image, you might want 76 | to respond with image dot slash 77 | 78 | 17 79 | 00:00:40,920 --> 00:00:42,990 80 | JIFF or image slash JPEG. 81 | 82 | 18 83 | 00:00:42,990 --> 00:00:46,280 84 | See the specification for the various 85 | file formats you need to detect. 86 | 87 | 19 88 | 00:00:46,280 --> 00:00:49,760 89 | But it really boils down to taking a 90 | look at the path, that you are past, 91 | 92 | 20 93 | 00:00:49,760 --> 00:00:52,870 94 | and looking at its file 95 | extension, the last few characters 96 | 97 | 21 98 | 00:00:52,870 --> 00:00:54,297 99 | after the trailing period or dot. 100 | 101 | 22 102 | 00:00:54,297 --> 00:00:57,130 103 | So we'll leave it to you with some 104 | of the hints in the specification 105 | 106 | 23 107 | 00:00:57,130 --> 00:01:00,170 108 | to figure out exactly how to find 109 | that dot and the file extension 110 | 111 | 24 112 | 00:01:00,170 --> 00:01:02,840 113 | so that you can do the 114 | mapping from one to the other. 115 | 116 | 25 117 | 00:01:02,840 --> 00:01:04,395 118 | >> Next up is the parse function. 119 | 120 | 26 121 | 00:01:04,395 --> 00:01:06,270 122 | So this one's a little 123 | more involved, in that 124 | 125 | 27 126 | 00:01:06,270 --> 00:01:08,590 127 | you need to take in that 128 | argument [INAUDIBLE], 129 | 130 | 28 131 | 00:01:08,590 --> 00:01:12,030 132 | it's iterated over it, character 133 | for character, or string by string, 134 | 135 | 29 136 | 00:01:12,030 --> 00:01:14,660 137 | in order to make sure 138 | that it meets exactly 139 | 140 | 30 141 | 00:01:14,660 --> 00:01:19,155 142 | the formal definition of that first 143 | request line, as per the specification. 144 | 145 | 31 146 | 00:01:19,155 --> 00:01:23,930 147 | And you need to load into absolute 148 | path that substring, that represents 149 | 150 | 32 151 | 00:01:23,930 --> 00:01:26,550 152 | something like, slash hello dot HTML. 153 | 154 | 33 155 | 00:01:26,550 --> 00:01:29,960 156 | Meanwhile, optionally, after that 157 | path might be a question mark 158 | 159 | 34 160 | 00:01:29,960 --> 00:01:32,240 161 | and then a query string 162 | like, q equals cats, 163 | 164 | 35 165 | 00:01:32,240 --> 00:01:35,310 166 | or q equals cats ampersand, and 167 | then another key value pair. 168 | 169 | 36 170 | 00:01:35,310 --> 00:01:38,380 171 | So you're going to need to 172 | step over those characters, 173 | 174 | 37 175 | 00:01:38,380 --> 00:01:41,150 176 | as well, up until the 177 | first space, in order 178 | 179 | 38 180 | 00:01:41,150 --> 00:01:47,327 181 | to create a string that stores 182 | inside of it the query string itself. 183 | 184 | 39 185 | 00:01:47,327 --> 00:01:49,410 186 | Next, you're going to 187 | implement the load function. 188 | 189 | 40 190 | 00:01:49,410 --> 00:01:52,493 191 | So it turns out, if you look through 192 | the source code, as the spec directs, 193 | 194 | 41 195 | 00:01:52,493 --> 00:01:54,210 196 | the load function is used in two places. 197 | 198 | 42 199 | 00:01:54,210 --> 00:01:57,420 200 | It's either used to load the 201 | output from the PHP Interpreter. 202 | 203 | 43 204 | 00:01:57,420 --> 00:01:59,700 205 | And we wrote all of 206 | the PHP handling code, 207 | 208 | 44 209 | 00:01:59,700 --> 00:02:01,840 210 | but it does need to 211 | use a function called 212 | 213 | 45 214 | 00:02:01,840 --> 00:02:06,350 215 | load, that essentially reads all of the 216 | bytes of output from PHP's Interpreter 217 | 218 | 46 219 | 00:02:06,350 --> 00:02:08,430 220 | into a big array. 221 | 222 | 47 223 | 00:02:08,430 --> 00:02:10,850 224 | >> That same function load 225 | is also used to load 226 | 227 | 48 228 | 00:02:10,850 --> 00:02:15,200 229 | into memory all of the bytes from a file 230 | like, a JIFF, or a JPEG, or dot HTML 231 | 232 | 49 233 | 00:02:15,200 --> 00:02:16,630 234 | file, that the user has requested. 235 | 236 | 50 237 | 00:02:16,630 --> 00:02:21,060 238 | So you will need to use some tricks and 239 | tools from problem set 4 in file IO, 240 | 241 | 51 242 | 00:02:21,060 --> 00:02:24,410 243 | but you should find that relatively 244 | familiar and in a nice way, hopefully, 245 | 246 | 52 247 | 00:02:24,410 --> 00:02:28,110 248 | of tying together the newer web 249 | stuff with the older file IO stuff. 250 | 251 | 53 252 | 00:02:28,110 --> 00:02:31,490 253 | >> Finally, in the indexes 254 | function, all you need to do 255 | 256 | 54 257 | 00:02:31,490 --> 00:02:34,570 258 | is to decide whether or not there 259 | exists some file effectively 260 | 261 | 55 262 | 00:02:34,570 --> 00:02:40,430 263 | called index dot HTML, or index dot PHP, 264 | inside of the directory, whose path you 265 | 266 | 56 267 | 00:02:40,430 --> 00:02:41,220 268 | are past. 269 | 270 | 57 271 | 00:02:41,220 --> 00:02:44,360 272 | The upside of this means that if 273 | the user does request a directory, 274 | 275 | 58 276 | 00:02:44,360 --> 00:02:47,318 277 | we're not just going to show him or 278 | her the contents of that directory, 279 | 280 | 59 281 | 00:02:47,318 --> 00:02:51,342 282 | we'll literally show them index dot 283 | HTML, or index dot PHP, by default. 284 | 285 | 60 286 | 00:02:51,342 --> 00:02:54,300 287 | But it's going to be left to you to 288 | figure out, using some of the hints 289 | 290 | 61 291 | 00:02:54,300 --> 00:02:56,350 292 | in the source code, that 293 | we've already given you, 294 | 295 | 62 296 | 00:02:56,350 --> 00:02:59,880 297 | how you can actually check 298 | whether a certain file exists 299 | 300 | 63 301 | 00:02:59,880 --> 00:03:03,380 302 | in the current directory, so that 303 | you can return the correct response. 304 | 305 | 64 306 | 00:03:03,380 --> 00:03:05,800 307 | >> So in the end there's 308 | relatively few bytes 309 | 310 | 65 311 | 00:03:05,800 --> 00:03:09,155 312 | that you need to take out of the 313 | problem set to implement the server's 314 | 315 | 66 316 | 00:03:09,155 --> 00:03:10,210 317 | incomplete functionality. 318 | 319 | 67 320 | 00:03:10,210 --> 00:03:13,180 321 | But definitely make sure you wrap 322 | your mind around as much of the code 323 | 324 | 68 325 | 00:03:13,180 --> 00:03:15,013 326 | as you can, taking 327 | comfort in that you don't 328 | 329 | 69 330 | 00:03:15,013 --> 00:03:18,160 331 | need to understand all of the 332 | lowest level networking code, all 333 | 334 | 70 335 | 00:03:18,160 --> 00:03:19,834 336 | of the lowest level file IO code. 337 | 338 | 71 339 | 00:03:19,834 --> 00:03:21,750 340 | Really, what we're doing 341 | with this problem set 342 | 343 | 72 344 | 00:03:21,750 --> 00:03:25,670 345 | is synthesizing the past several problem 346 | sets, introducing a bit of WebLogic, 347 | 348 | 73 349 | 00:03:25,670 --> 00:03:28,802 350 | and networking concepts, 351 | so that ultimately you 352 | 353 | 74 354 | 00:03:28,802 --> 00:03:31,760 355 | build something that's really quite 356 | interesting, really quite powerful, 357 | 358 | 75 359 | 00:03:31,760 --> 00:03:33,468 360 | but still using the 361 | same building blocks, 362 | 363 | 76 364 | 00:03:33,468 --> 00:03:36,310 365 | that we've been using for some time. 366 | -------------------------------------------------------------------------------- /2016/README.md: -------------------------------------------------------------------------------- 1 | # Translators 2 | 3 | | Language | Name | Role | 4 | | ------------- | ---------------- | ------------- | 5 | | English | Colton Ogden | Moderator | 6 | | Spanish | Walter J. Méndez | Moderator | 7 | | Arabic | Mohamed Ashraf | Moderator | 8 | | Urdu | Rahul Nagshi | Moderator | 9 | 10 | ## Lecture Subtitles 11 | 12 | | Episode | English | Spanish | Arabic | Hindi | Portuguese | 13 | | ------------- | ------------- | ------------- | ------------- | ------------- | ------------- | 14 | | Week 0 | ✔ | | | | | 15 | | Week 1 | ✔ | | | | | 16 | | Week 2 | ✔ | | | | | 17 | | Week 3 | ✔ | | | | | 18 | | Week 4 | ✔ | | | | | 19 | | Week 5 | ✔ | | | | | 20 | 21 | 22 | ## Lecture Chapters 23 | 24 | | Episode | English | Spanish | Arabic | Hindi | Portuguese | 25 | | ------------- | ------------- | ------------- | ------------- | ------------- | ------------- | 26 | | Week 0 | ✔ | ✔ | | | | 27 | | Week 1 | ✔ | | | | | 28 | | Week 2 | ✔ | | | | | 29 | | Week 3 | ✔ | | | | | 30 | | Week 4 | ✔ | | | | | 31 | | Week 5 | ✔ | | | | | 32 | 33 | 34 | ## Walkthrough Subtitles 35 | 36 | | Episode | English | Spanish | Arabic | Hindi | Portuguese | 37 | | ------------- | ------------- | ------------- | ------------- | ------------- | ------------- | 38 | | Caesar | ✔ | | | | | 39 | | Check | ✔ | | | | | 40 | | Credit | ✔ | | | | | 41 | | Fifteen | ✔ | | | | | 42 | | Greedy | ✔ | | | | | 43 | | Hello | ✔ | | | | | 44 | | Initials Less | ✔ | | | | | 45 | | Initials More | ✔ | | | | | 46 | | Load | ✔ | | | | | 47 | | Mario Less | ✔ | | | | | 48 | | Mario More | ✔ | | | | | 49 | | Recover | ✔ | | | | | 50 | | Resize Less | ✔ | | | | | 51 | | Resize More | ✔ | | | | | 52 | | Search | ✔ | | | | | 53 | | Size | ✔ | | | | | 54 | | Sort Less | ✔ | | | | | 55 | | Sort More | ✔ | | | | | 56 | | Speller | ✔ | | | | | 57 | | Unload | ✔ | | | | | 58 | | Vigenere | ✔ | | | | | 59 | | Water | ✔ | | | | | 60 | | Whodunit | ✔ | | | | | 61 | -------------------------------------------------------------------------------- /2016/ar/lectures/chapters/README.md: -------------------------------------------------------------------------------- 1 | 2016 Arabic lecture chapters. 2 | -------------------------------------------------------------------------------- /2016/ar/lectures/chapters/week0Harvard.vtt.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs50/tracks/428db1668f526352b1b5bcf92e329464dc66cb98/2016/ar/lectures/chapters/week0Harvard.vtt.docx -------------------------------------------------------------------------------- /2016/ar/lectures/chapters/week1.vtt.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs50/tracks/428db1668f526352b1b5bcf92e329464dc66cb98/2016/ar/lectures/chapters/week1.vtt.docx -------------------------------------------------------------------------------- /2016/ar/lectures/chapters/week2.vtt.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs50/tracks/428db1668f526352b1b5bcf92e329464dc66cb98/2016/ar/lectures/chapters/week2.vtt.docx -------------------------------------------------------------------------------- /2016/ar/lectures/chapters/week3.vtt.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs50/tracks/428db1668f526352b1b5bcf92e329464dc66cb98/2016/ar/lectures/chapters/week3.vtt.docx -------------------------------------------------------------------------------- /2016/ar/lectures/chapters/week4.vtt.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs50/tracks/428db1668f526352b1b5bcf92e329464dc66cb98/2016/ar/lectures/chapters/week4.vtt.docx -------------------------------------------------------------------------------- /2016/ar/lectures/chapters/week5.vtt.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs50/tracks/428db1668f526352b1b5bcf92e329464dc66cb98/2016/ar/lectures/chapters/week5.vtt.docx -------------------------------------------------------------------------------- /2016/ar/lectures/subtitles/README.md: -------------------------------------------------------------------------------- 1 | 2016 Arabic lecture subtitles. 2 | -------------------------------------------------------------------------------- /2016/en/lectures/chapters/week0harvard.vtt: -------------------------------------------------------------------------------- 1 | WEBVTT 2 | 3 | 1 4 | 00:00:00.000 --> 00:01:58.000 5 | This is CS50. 6 | 7 | 2 8 | 00:01:58.000 --> 00:03:37.000 9 | Course Overview 10 | 11 | 3 12 | 00:03:37.000 --> 00:09:06.000 13 | Introducing Binary 14 | 15 | 4 16 | 00:09:06.000 --> 00:12:05.000 17 | Binary Bulbs 18 | 19 | 5 20 | 00:12:05.000 --> 00:13:52.000 21 | ASCII 22 | 23 | 6 24 | 00:13:52.000 --> 00:15:32.000 25 | RGB 26 | 27 | 7 28 | 00:15:32.000 --> 00:21:57.000 29 | Taking Attendance 30 | 31 | 8 32 | 00:21:57.000 --> 00:27:59.000 33 | Finding Mike Smith 34 | 35 | 9 36 | 00:27:59.000 --> 00:30:55.000 37 | A Good Algorithm 38 | 39 | 10 40 | 00:30:55.000 --> 00:36:58.000 41 | What's New 42 | 43 | 11 44 | 00:36:58.000 --> 00:41:44.000 45 | CS50 Staff 46 | 47 | 12 48 | 00:41:44.000 --> 00:43:44.000 49 | Course Events 50 | 51 | 13 52 | 00:43:44.000 --> 00:45:46.000 53 | Staff Video 54 | 55 | 14 56 | 00:45:46.000 --> 00:51:34.000 57 | Introducing Scratch 58 | 59 | 15 60 | 00:51:34.000 --> 00:56:23.000 61 | Oscartime 62 | 63 | 16 64 | 00:56:23.000 --> 01:00:32.000 65 | The Scratch Editor 66 | 67 | 17 68 | 01:00:32.000 --> 01:02:39.000 69 | Scratch in Motion 70 | 71 | 18 72 | 01:02:39.000 --> 01:04:55.000 73 | counting sheep 74 | 75 | 19 76 | 01:04:55.000 --> 01:05:37.000 77 | pet the cat 78 | 79 | 20 80 | 01:05:37.000 --> 01:06:16.000 81 | don't pet the cat 82 | 83 | 21 84 | 01:06:16.000 --> 01:08:01.000 85 | threads 86 | 87 | 22 88 | 01:08:01.000 --> 01:09:43.000 89 | hi hi hi 90 | 91 | 23 92 | 01:09:43.000 --> 01:11:01.000 93 | Pokémon Go 94 | 95 | 24 96 | 01:11:01.000 --> 01:12:06.000 97 | cough-0 98 | 99 | 25 100 | 01:12:06.000 --> 01:13:08.000 101 | cough-2 102 | 103 | 26 104 | 01:13:08.000 --> 01:15:24.000 105 | cough-3 106 | 107 | 27 108 | 01:15:24.000 --> 01:17:28.000 109 | What Awaits 110 | 111 | 28 112 | 01:17:28.000 --> 01:18:40.000 113 | Outro 114 | -------------------------------------------------------------------------------- /2016/en/lectures/chapters/week0yale.vtt: -------------------------------------------------------------------------------- 1 | WEBVTT 2 | 3 | 1 4 | 00:00:00.000 --> 00:02:46.000 5 | Introductions 6 | 7 | 2 8 | 00:02:46.000 --> 00:06:50.000 9 | This is CS50. 10 | 11 | 3 12 | 00:06:50.000 --> 00:08:55.000 13 | Problem Solving 14 | 15 | 4 16 | 00:08:55.000 --> 00:15:48.000 17 | Introducing Binary 18 | 19 | 5 20 | 00:15:48.000 --> 00:18:03.000 21 | ASCII 22 | 23 | 6 24 | 00:18:03.000 --> 00:20:10.000 25 | RGB 26 | 27 | 7 28 | 00:20:12.000 --> 00:27:40.000 29 | Finding Mike Smith 30 | 31 | 8 32 | 00:27:38.000 --> 00:32:03.000 33 | Good Algorithms 34 | 35 | 9 36 | 00:32:03.000 --> 00:40:27.000 37 | Course Overview 38 | 39 | 10 40 | 00:40:27.000 --> 00:45:26.000 41 | Staff Introductions 42 | 43 | 11 44 | 00:45:26.000 --> 00:47:18.000 45 | Staff Video 46 | 47 | 12 48 | 00:47:15.000 --> 00:51:43.000 49 | Introducing Scratch 50 | 51 | 13 52 | 00:51:43.000 --> 00:53:13.000 53 | The Scratch Editor 54 | 55 | 14 56 | 00:53:13.000 --> 00:56:18.000 57 | Meowing 58 | 59 | 15 60 | 00:56:18.000 --> 00:59:25.000 61 | Moving 62 | 63 | 16 64 | 00:59:25.000 --> 01:00:40.000 65 | pet the cat 66 | 67 | 17 68 | 01:00:40.000 --> 01:02:40.000 69 | threads 70 | 71 | 18 72 | 01:02:40.000 --> 01:03:22.000 73 | events 74 | 75 | 19 76 | 01:03:22.000 --> 01:04:12.000 77 | hi hi hi 78 | 79 | 20 80 | 01:04:12.000 --> 01:07:05.000 81 | Pokémon Go 82 | 83 | 21 84 | 01:07:05.000 --> 01:12:12.000 85 | Ivy's Hardest Game (Remix) 86 | 87 | 22 88 | 01:12:12.000 --> 01:12:44.000 89 | Closing Remarks 90 | 91 | 23 92 | 01:12:44.000 --> 01:14:40.000 93 | Teaser Video 94 | 95 | 24 96 | 01:14:40.000 --> 01:15:54.000 97 | Outro 98 | -------------------------------------------------------------------------------- /2016/en/lectures/chapters/week1.vtt: -------------------------------------------------------------------------------- 1 | WEBVTT 2 | 3 | 1 4 | 00:00:00.000 --> 00:01:11.000 5 | Recap 6 | 7 | 2 8 | 00:01:11.000 --> 00:02:56.000 9 | Scratch vs. C 10 | 11 | 3 12 | 00:02:56.000 --> 00:04:13.000 13 | Loops 14 | 15 | 4 16 | 00:04:13.000 --> 00:06:16.000 17 | Variables 18 | 19 | 5 20 | 00:06:16.000 --> 00:07:28.000 21 | Conditions 22 | 23 | 6 24 | 00:07:28.000 --> 00:08:57.000 25 | Arrays 26 | 27 | 7 28 | 00:08:57.000 --> 00:10:23.000 29 | hello, C 30 | 31 | 8 32 | 00:10:23.000 --> 00:13:20.000 33 | Compiling 34 | 35 | 9 36 | 00:13:20.000 --> 00:17:54.000 37 | The CS50 IDE 38 | 39 | 10 40 | 00:17:54.000 --> 00:18:36.000 41 | The Command Line 42 | 43 | 11 44 | 00:18:36.000 --> 00:27:38.000 45 | clang 46 | 47 | 12 48 | 00:27:38.000 --> 00:28:34.000 49 | Linux Commands 50 | 51 | 13 52 | 00:28:34.000 --> 00:38:28.000 53 | The CS50 Library 54 | 55 | 14 56 | 00:38:28.000 --> 00:39:10.000 57 | Improving the UX 58 | 59 | 15 60 | 00:39:10.000 --> 00:40:11.000 61 | Layering 62 | 63 | 16 64 | 00:40:11.000 --> 00:43:24.000 65 | get_int 66 | 67 | 17 68 | 00:43:24.000 --> 00:47:46.000 69 | adder.c 70 | 71 | 18 72 | 00:47:46.000 --> 00:52:02.000 73 | ints.c 74 | 75 | 19 76 | 00:52:02.000 --> 00:54:29.000 77 | floats.c 78 | 79 | 20 80 | 00:54:29.000 --> 00:55:19.000 81 | Data Types 82 | 83 | 21 84 | 00:55:19.000 --> 00:58:07.000 85 | sizeof.c 86 | 87 | 22 88 | 00:58:07.000 --> 00:59:54.000 89 | Memory 90 | 91 | 23 92 | 00:59:54.000 --> 01:01:36.000 93 | Overflow 94 | 95 | 24 96 | 01:01:36.000 --> 01:10:43.000 97 | overflow.c 98 | 99 | 25 100 | 01:10:43.000 --> 01:12:38.000 101 | Bugs 102 | 103 | 26 104 | 01:12:38.000 --> 01:13:38.000 105 | Floating-Point Imprecision 106 | 107 | 27 108 | 01:13:38.000 --> 01:18:39.000 109 | imprecision.c 110 | 111 | 28 112 | 01:18:39.000 --> 01:27:21.000 113 | Imprecision in the Real World 114 | 115 | 29 116 | 01:27:21.000 --> 01:28:46.000 117 | Variable Recap 118 | 119 | 30 120 | 01:28:46.000 --> 01:29:24.000 121 | Escape Sequences 122 | 123 | 31 124 | 01:29:24.000 --> 01:33:33.000 125 | conditions.c 126 | 127 | 32 128 | 01:33:33.000 --> 01:37:28.000 129 | logical.c 130 | 131 | 33 132 | 01:37:28.000 --> 01:41:43.000 133 | switch.c 134 | 135 | 34 136 | 01:41:43.000 --> 01:49:02.000 137 | prototype.c 138 | 139 | 35 140 | 01:49:02.000 --> 01:52:58.000 141 | return.c 142 | 143 | 36 144 | 01:52:58.000 --> 01:54:01.000 145 | get.c 146 | 147 | 37 148 | 01:54:01.000 --> 02:03:01.000 149 | cough.c 150 | 151 | 38 152 | 02:03:01.000 --> 02:07:17.000 153 | Compiling in Detail 154 | 155 | 39 156 | 02:07:17.000 --> 02:09:16.000 157 | Takeaways 158 | 159 | 40 160 | 02:09:16.000 --> 02:10:03.000 161 | Outro 162 | -------------------------------------------------------------------------------- /2016/en/lectures/chapters/week2.vtt: -------------------------------------------------------------------------------- 1 | WEBVTT 2 | 3 | 1 4 | 00:00:00.000 --> 00:04:33.000 5 | ?????? ??????? ????? 6 | 7 | 2 8 | 00:04:33.000 --> 00:05:05.000 9 | ????? ??????? 10 | 11 | 3 12 | 00:05:05.000 --> 00:09:12.000 13 | ?? ???0 14 | 15 | 4 16 | 00:09:12.000 --> 00:12:49.000 17 | ?? ??? 1 18 | 19 | 5 20 | 00:12:49.000 --> 00:18:11.000 21 | ?? ??? 2 22 | 23 | 6 24 | 00:18:11.000 --> 00:22:19.000 25 | ?? ??? 3 26 | 27 | 7 28 | 00:22:19.000 --> 00:29:04.000 29 | ??????? 50 30 | 31 | 8 32 | 00:29:04.000 --> 00:31:46.000 33 | ????? ????? ???????? 34 | 9 35 | 00:31:46.000 --> 00:35:18.000 36 | ???? ??? ???????? 37 | 38 | 10 39 | 00:35:18.000 --> 00:39:07.000 40 | ??????? ?????????? 41 | 42 | 11 43 | 00:39:07.000 --> 00:39:58.000 44 | ???? 45 | 46 | 12 47 | 00:39:58.000 --> 00:41:00.000 48 | ??????? 49 | 50 | 13 51 | 00:41:00.000 --> 00:44:21.000 52 | ????? 53 | 54 | 14 55 | 00:44:21.000 --> 00:46:18.000 56 | ????? ??????? ????? 57 | 15 58 | 00:46:18.000 --> 00:48:06.000 59 | ??????? 60 | ????? ??? ????? ?? ?????? 61 | 62 | 16 63 | 00:48:06.000 --> 00:57:35.000 64 | ??????? 0 65 | 66 | 17 67 | 00:57:35.000 --> 01:01:20.000 68 | ??????? 1 69 | 70 | 18 71 | 01:01:20.000 --> 01:02:39.000 72 | ????? ??????? 73 | 74 | 19 75 | 01:02:39.000 --> 01:06:19.000 76 | ????? ?????? ???????? ??????? 0 77 | 78 | 20 79 | 01:06:19.000 --> 01:09:04.000 80 | ????? ?????? ???????? ??????? 1 81 | 82 | 21 83 | 01:09:04.000 --> 01:12:41.000 84 | ????? ?????? ?????????? ???? ???? 0 85 | 86 | 22 87 | 01:12:41.000 --> 01:13:47.000 88 | ????? ?????? ?????????? ???? ???? 2 89 | 90 | 23 91 | 01:13:47.000 --> 01:16:31.000 92 | ??? 93 | 94 | 24 95 | 01:16:31.000 --> 01:17:40.000 96 | Strlen 97 | ??? ???? ?? ??? ?? C ??? ?????? ? "??? ???????" 98 | 99 | 25 100 | 01:17:40.000 --> 01:22:49.000 101 | ??????? ???? ?? ??????? 102 | ????? ??? ????? ?? ?????? 103 | 104 | 26 105 | 01:22:49.000 --> 01:25:09.000 106 | ??????? ???? ?? ???? strlen 107 | 108 | 27 109 | 01:25:09.000 --> 01:26:53.000 110 | ?????? ??? ??????? 111 | 112 | 28 113 | 01:26:53.000 --> 01:34:22.000 114 | ?????? 0 115 | 116 | 29 117 | 01:34:22.000 --> 01:36:35.000 118 | ?????? 1 119 | 120 | 30 121 | 01:36:35.000 --> 01:42:26.000 122 | ?????? 2 123 | 124 | 31 125 | 01:42:26.000 --> 01:46:36.000 126 | ?????? 127 | 128 | 32 129 | 01:46:36.000 --> 01:49:28.000 130 | ????????? ??????? 131 | 132 | 33 133 | 01:49:28.000 --> 01:50:53.000 134 | ??????? 135 | -------------------------------------------------------------------------------- /2016/en/lectures/chapters/week3.vtt: -------------------------------------------------------------------------------- 1 | WEBVTT 2 | 3 | 1 4 | 00:00:00.000 --> 00:04:32.000 5 | Week 2 Recap 6 | 7 | 2 8 | 00:04:32.000 --> 00:08:23.000 9 | Finding 50 10 | 11 | 3 12 | 00:08:23.000 --> 00:11:56.000 13 | Linear Search 14 | 15 | 4 16 | 00:11:56.000 --> 00:15:18.000 17 | Binary Search 18 | 19 | 5 20 | 00:15:18.000 --> 00:19:13.000 21 | Memories 22 | 23 | 6 24 | 00:19:13.000 --> 00:23:08.000 25 | Sorting Blue Books 26 | 27 | 7 28 | 00:23:08.000 --> 00:25:57.000 29 | Sorting Playing Cards 30 | 31 | 8 32 | 00:25:57.000 --> 00:28:31.000 33 | Sorting Humans 34 | 35 | 9 36 | 00:28:31.000 --> 00:31:58.000 37 | Selection Sort 38 | 39 | 10 40 | 00:31:58.000 --> 00:35:07.000 41 | Bubble Sort 42 | 43 | 11 44 | 00:35:07.000 --> 00:37:30.000 45 | Insertion Sort 46 | 47 | 12 48 | 00:37:30.000 --> 00:38:42.000 49 | Bubble Sort Pseudocode 50 | 51 | 13 52 | 00:38:42.000 --> 00:39:22.000 53 | Selection Sort Pseudocode 54 | 55 | 14 56 | 00:39:22.000 --> 00:40:19.000 57 | Insertion Sort Pseudocode 58 | 59 | 15 60 | 00:40:19.000 --> 00:45:11.000 61 | Algorithm Running Time 62 | 63 | 16 64 | 00:45:11.000 --> 00:51:10.000 65 | Big-O Notation 66 | 67 | 17 68 | 00:51:10.000 --> 00:56:33.000 69 | Omega Notation 70 | 71 | 18 72 | 00:56:33.000 --> 00:56:54.000 73 | Theta Notation 74 | 75 | 19 76 | 00:56:54.000 --> 01:02:00.000 77 | Visual Sorting 78 | 79 | 20 80 | 01:02:00.000 --> 01:03:04.000 81 | Recursion 82 | 83 | 21 84 | 01:03:04.000 --> 01:17:23.000 85 | Merge Sort 86 | 87 | 22 88 | 01:17:23.000 --> 01:19:15.000 89 | sigma0 90 | 91 | 23 92 | 01:19:15.000 --> 01:22:58.000 93 | sigma1 94 | 95 | 24 96 | 01:22:58.000 --> 01:24:32.000 97 | Google Interview 98 | 99 | 25 100 | 01:24:32.000 --> 01:25:16.000 101 | Outro 102 | -------------------------------------------------------------------------------- /2016/en/lectures/chapters/week4.vtt: -------------------------------------------------------------------------------- 1 | WEBVTT 2 | 3 | 1 4 | 00:00:00.000 --> 00:03:24.000 5 | Week 3 in Review 6 | 7 | 2 8 | 00:03:24.000 --> 00:04:20.000 9 | Strings Are a Lie 10 | 11 | 3 12 | 00:04:20.000 --> 00:06:34.000 13 | compare0 14 | 15 | 4 16 | 00:06:34.000 --> 00:10:05.000 17 | copy0 18 | 19 | 5 20 | 00:10:05.000 --> 00:15:49.000 21 | noswap 22 | 23 | 6 24 | 00:15:49.000 --> 00:17:35.000 25 | Program Memory 26 | 27 | 7 28 | 00:17:35.000 --> 00:22:15.000 29 | The Stack 30 | 31 | 8 32 | 00:22:15.000 --> 00:31:05.000 33 | get_string() in Detail 34 | 35 | 9 36 | 00:31:05.000 --> 00:31:29.000 37 | Pointer Fun Preview 38 | 39 | 10 40 | 00:31:29.000 --> 00:32:05.000 41 | Taking Off the Training Wheels 42 | 43 | 11 44 | 00:32:05.000 --> 00:32:39.000 45 | compare1 46 | 47 | 12 48 | 00:32:39.000 --> 00:34:45.000 49 | char * 50 | 51 | 13 52 | 00:34:45.000 --> 00:36:42.000 53 | strcmp 54 | 55 | 14 56 | 00:36:42.000 --> 00:37:02.000 57 | copy1 58 | 59 | 15 60 | 00:37:02.000 --> 00:45:07.000 61 | malloc 62 | 63 | 16 64 | 00:45:07.000 --> 00:49:27.000 65 | Introducing Pointers 66 | 67 | 17 68 | 00:49:27.000 --> 00:55:04.000 69 | swap 70 | 71 | 18 72 | 00:55:04.000 --> 00:56:05.000 73 | Proverbial Lightbulb 74 | 75 | 19 76 | 00:56:05.000 --> 00:56:18.000 77 | Pointer Arithmetic 78 | 79 | 20 80 | 00:56:18.000 --> 00:59:55.000 81 | pointers 82 | 83 | 21 84 | 00:59:55.000 --> 01:03:06.000 85 | Pointer Gotchas 86 | 87 | 22 88 | 01:03:06.000 --> 01:06:26.000 89 | Pointer Fun with Binky 90 | 91 | 23 92 | 01:06:26.000 --> 01:07:02.000 93 | Memory Leaks 94 | 95 | 24 96 | 01:07:02.000 --> 01:07:30.000 97 | valgrind 98 | 99 | 25 100 | 01:07:30.000 --> 01:14:42.000 101 | memory 102 | 103 | 26 104 | 01:14:42.000 --> 01:16:01.000 105 | The Heap 106 | 107 | 27 108 | 01:16:01.000 --> 01:17:26.000 109 | Types of Overflow 110 | 111 | 28 112 | 01:17:26.000 --> 01:21:20.000 113 | Buffer Overflow 114 | 115 | 29 116 | 01:21:20.000 --> 01:26:53.000 117 | The Stack in More Detail 118 | 119 | 30 120 | 01:26:53.000 --> 01:28:38.000 121 | Zooming In 122 | 123 | 31 124 | 01:28:38.000 --> 01:31:04.000 125 | Representing Images 126 | 127 | 32 128 | 01:31:04.000 --> 01:32:11.000 129 | JPEG 130 | 131 | 33 132 | 01:32:11.000 --> 01:37:10.000 133 | Hexadecimal 134 | 135 | 34 136 | 01:37:10.000 --> 01:40:24.000 137 | BMP 138 | 139 | 35 140 | 01:40:24.000 --> 01:42:19.000 141 | struct 142 | 143 | 36 144 | 01:42:19.000 --> 01:45:00.000 145 | structs0 146 | 147 | 37 148 | 01:45:00.000 --> 01:47:55.000 149 | structs1 150 | 151 | 38 152 | 01:47:55.000 --> 01:48:43.000 153 | CSV 154 | 155 | 39 156 | 01:48:43.000 --> 01:51:02.000 157 | Enhance 158 | 159 | 40 160 | 01:51:02.000 --> 01:51:42.000 161 | Outro 162 | -------------------------------------------------------------------------------- /2016/en/lectures/chapters/week5.vtt: -------------------------------------------------------------------------------- 1 | WEBVTT 2 | 3 | 1 4 | 00:00:00.000 --> 00:07:22.000 5 | Week 4 Recap 6 | 7 | 2 8 | 00:07:22.000 --> 00:10:45.000 9 | Limitations of Arrays 10 | 11 | 3 12 | 00:10:45.000 --> 00:13:11.000 13 | Lists 14 | 15 | 4 16 | 00:13:11.000 --> 00:15:10.000 17 | Nodes 18 | 19 | 5 20 | 00:15:10.000 --> 00:20:39.000 21 | Linked Lists 22 | 23 | 6 24 | 00:20:39.000 --> 00:26:52.000 25 | List of Humans 26 | 27 | 7 28 | 00:26:52.000 --> 00:28:14.000 29 | List Operations 30 | 31 | 8 32 | 00:28:14.000 --> 00:40:11.000 33 | Implementing search 34 | 35 | 9 36 | 00:40:11.000 --> 00:41:26.000 37 | Linked List Tradeoffs 38 | 39 | 10 40 | 00:41:26.000 --> 00:43:57.000 41 | Stacks 42 | 43 | 11 44 | 00:43:57.000 --> 00:47:30.000 45 | Implementing a Stack 46 | 47 | 12 48 | 00:47:30.000 --> 00:49:43.000 49 | Queues 50 | 51 | 13 52 | 00:49:43.000 --> 00:54:40.000 53 | Implementing a Queue 54 | 55 | 14 56 | 00:54:40.000 --> 00:56:06.000 57 | Abstract Data Types 58 | 59 | 15 60 | 00:56:06.000 --> 00:57:53.000 61 | Jack Learns the Facts 62 | 63 | 16 64 | 00:57:53.000 --> 01:00:59.000 65 | Trees 66 | 67 | 17 68 | 01:00:59.000 --> 01:07:56.000 69 | Binary Search Trees 70 | 71 | 18 72 | 01:07:56.000 --> 01:14:26.000 73 | Implementing a Tree 74 | 75 | 19 76 | 01:14:26.000 --> 01:28:42.000 77 | Huffman Coding 78 | 79 | 20 80 | 01:28:42.000 --> 01:30:37.000 81 | Hash Tables 82 | 83 | 21 84 | 01:30:37.000 --> 01:33:31.000 85 | Buckets 86 | 87 | 22 88 | 01:33:31.000 --> 01:36:21.000 89 | Linear Probing 90 | 91 | 23 92 | 01:36:21.000 --> 01:39:05.000 93 | Separate Chaining 94 | 95 | 24 96 | 01:39:05.000 --> 01:45:25.000 97 | Tries 98 | 99 | 25 100 | 01:45:25.000 --> 01:46:43.000 101 | Outro 102 | -------------------------------------------------------------------------------- /2016/en/walkthroughs/check.srt: -------------------------------------------------------------------------------- 1 | 1 2 | 00:00:00,000 --> 00:00:00,762 3 | 4 | 5 | 2 6 | 00:00:00,762 --> 00:00:02,720 7 | SPEAKER: Now that we've 8 | created our dictionary, 9 | 10 | 3 11 | 00:00:02,720 --> 00:00:05,990 12 | it's time to implement check, 13 | which will check whether a given 14 | 15 | 4 16 | 00:00:05,990 --> 00:00:08,800 17 | string is in our dictionary or not. 18 | 19 | 5 20 | 00:00:08,800 --> 00:00:11,740 21 | Check is going to be a 22 | case insensitive function. 23 | 24 | 6 25 | 00:00:11,740 --> 00:00:14,620 26 | That means that whether or not 27 | the word that you're checking 28 | 29 | 7 30 | 00:00:14,620 --> 00:00:18,900 31 | contains uppercase letters or lowercase 32 | letters or a mixture there of, 33 | 34 | 8 35 | 00:00:18,900 --> 00:00:22,470 36 | it's going to return true as long 37 | as any combination of those cases 38 | 39 | 9 40 | 00:00:22,470 --> 00:00:24,490 41 | is found in the dictionary. 42 | 43 | 10 44 | 00:00:24,490 --> 00:00:26,350 45 | Then finally, we're 46 | going to let you assume 47 | 48 | 11 49 | 00:00:26,350 --> 00:00:30,840 50 | that the strings that you're passed in, 51 | will only have alphabetical characters 52 | 53 | 12 54 | 00:00:30,840 --> 00:00:32,040 55 | or apostrophes. 56 | 57 | 13 58 | 00:00:32,040 --> 00:00:37,010 59 | So no need to worry about cases with 60 | any numbers or other characters. 61 | 62 | 14 63 | 00:00:37,010 --> 00:00:39,310 64 | The premise of check is 65 | that if the word exists, 66 | 67 | 15 68 | 00:00:39,310 --> 00:00:42,950 69 | then you'll be able to find it in 70 | your dictionary data structure. 71 | 72 | 16 73 | 00:00:42,950 --> 00:00:45,430 74 | I'm going to follow the 75 | same order as I did in load, 76 | 77 | 17 78 | 00:00:45,430 --> 00:00:48,800 79 | so we're going to talk about 80 | linked lists and hashtables first. 81 | 82 | 18 83 | 00:00:48,800 --> 00:00:51,070 84 | And then, we'll talk about tries. 85 | 86 | 19 87 | 00:00:51,070 --> 00:00:55,140 88 | In a hashtable dictionary, which 89 | bucket would the word be in? 90 | 91 | 20 92 | 00:00:55,140 --> 00:00:56,070 93 | Remember that. 94 | 95 | 21 96 | 00:00:56,070 --> 00:01:00,720 97 | A hashtable is simply an array of linked 98 | lists where each element of the array 99 | 100 | 22 101 | 00:01:00,720 --> 00:01:02,580 102 | is a node pointer. 103 | 104 | 23 105 | 00:01:02,580 --> 00:01:05,590 106 | So then, once we know which 107 | linked list to search, 108 | 109 | 24 110 | 00:01:05,590 --> 00:01:08,080 111 | we're going to use the 112 | string case comparison 113 | 114 | 25 115 | 00:01:08,080 --> 00:01:11,400 116 | function to compare those two strings. 117 | 118 | 26 119 | 00:01:11,400 --> 00:01:15,020 120 | So how do we search that bucket 121 | for our word or in other words, 122 | 123 | 27 124 | 00:01:15,020 --> 00:01:17,590 125 | traverse a linked list? 126 | 127 | 28 128 | 00:01:17,590 --> 00:01:20,460 129 | Well let's assume first, 130 | that I've declared 131 | 132 | 29 133 | 00:01:20,460 --> 00:01:24,620 134 | a node pointer, called head, that points 135 | to the very first node in a linked 136 | 137 | 30 138 | 00:01:24,620 --> 00:01:25,790 139 | list. 140 | 141 | 31 142 | 00:01:25,790 --> 00:01:29,890 143 | Then I declare another node 144 | pointer, called cursor in this case, 145 | 146 | 32 147 | 00:01:29,890 --> 00:01:34,220 148 | that points to the very same node 149 | that the head pointer points to. 150 | 151 | 33 152 | 00:01:34,220 --> 00:01:37,090 153 | Notice here, that when I 154 | created the cursor pointer, 155 | 156 | 34 157 | 00:01:37,090 --> 00:01:39,480 158 | I didn't malloc any space. 159 | 160 | 35 161 | 00:01:39,480 --> 00:01:41,460 162 | That's because I'm 163 | not making a new node, 164 | 165 | 36 166 | 00:01:41,460 --> 00:01:43,850 167 | I'm simply creating a 168 | pointer that will point 169 | 170 | 37 171 | 00:01:43,850 --> 00:01:46,670 172 | to preexisting nodes in my linked list. 173 | 174 | 38 175 | 00:01:46,670 --> 00:01:48,750 176 | So then, we have a 177 | loop that will execute 178 | 179 | 39 180 | 00:01:48,750 --> 00:01:51,130 181 | as long as the cursor is not null. 182 | 183 | 40 184 | 00:01:51,130 --> 00:01:54,590 185 | Within that loop, you have 186 | space to do some process, 187 | 188 | 41 189 | 00:01:54,590 --> 00:01:59,220 190 | some repeated process on every single 191 | node, whether it is change the value 192 | 193 | 42 194 | 00:01:59,220 --> 00:02:03,010 195 | or calculate something or in 196 | this case, compare strings. 197 | 198 | 43 199 | 00:02:03,010 --> 00:02:06,110 200 | After you've done that, 201 | then you can reassign cursor 202 | 203 | 44 204 | 00:02:06,110 --> 00:02:08,830 205 | to whatever that node is pointing to. 206 | 207 | 45 208 | 00:02:08,830 --> 00:02:12,940 209 | And then, continue your loop 210 | until cursor points to null. 211 | 212 | 46 213 | 00:02:12,940 --> 00:02:15,150 214 | Now how do we traverse a try? 215 | 216 | 47 217 | 00:02:15,150 --> 00:02:17,250 218 | Well for each letter in 219 | the input word, then we'll 220 | 221 | 48 222 | 00:02:17,250 --> 00:02:21,040 223 | go to the corresponding element 224 | in children in that try. 225 | 226 | 49 227 | 00:02:21,040 --> 00:02:23,910 228 | If it's null, then that 229 | means the word is misspelled. 230 | 231 | 50 232 | 00:02:23,910 --> 00:02:26,540 233 | But if it's not, then we 234 | can move to the next letter 235 | 236 | 51 237 | 00:02:26,540 --> 00:02:29,240 238 | until we reach the 239 | end of the input word. 240 | 241 | 52 242 | 00:02:29,240 --> 00:02:33,530 243 | Now even if we've successfully followed 244 | every single letter down our try, 245 | 246 | 53 247 | 00:02:33,530 --> 00:02:36,060 248 | then that doesn't necessarily 249 | mean that our input 250 | 251 | 54 252 | 00:02:36,060 --> 00:02:39,130 253 | word is a word in our dictionary. 254 | 255 | 55 256 | 00:02:39,130 --> 00:02:43,080 257 | The final step that we'll need to do 258 | is to check whether the Boolean is 259 | 260 | 56 261 | 00:02:43,080 --> 00:02:44,740 262 | word is true or not. 263 | 264 | 57 265 | 00:02:44,740 --> 00:02:46,730 266 | If true, we can return true. 267 | 268 | 58 269 | 00:02:46,730 --> 00:02:49,810 270 | If false, then that's an invalid word. 271 | 272 | 59 273 | 00:02:49,810 --> 00:02:52,060 274 | Now that you know how to 275 | traverse your data structure, 276 | 277 | 60 278 | 00:02:52,060 --> 00:02:54,130 279 | you can get to checking. 280 | 281 | 61 282 | 00:02:54,130 --> 00:02:55,332 -------------------------------------------------------------------------------- /2016/en/walkthroughs/credit.srt: -------------------------------------------------------------------------------- 1 | 1 2 | 00:00:00,000 --> 00:00:00,820 3 | 4 | 2 5 | 00:00:00,820 --> 00:00:02,560 6 | >> Zamyla Chan: Let's check your credit. 7 | 8 | 3 9 | 00:00:02,560 --> 00:00:06,360 10 | In this problem, we'll prompt the user 11 | for an input of a credit card number. 12 | 13 | 4 14 | 00:00:06,360 --> 00:00:10,090 15 | Then we'll run that credit card 16 | number to see if it's valid. 17 | 18 | 5 19 | 00:00:10,090 --> 00:00:13,430 20 | If so, we'll print the company 21 | that that credit card belongs to. 22 | 23 | 6 24 | 00:00:13,430 --> 00:00:17,520 25 | Otherwise, we'll tell the user 26 | that that card is invalid. 27 | 28 | 7 29 | 00:00:17,520 --> 00:00:20,210 30 | >> Let's jump right in with 31 | prompting for user input. 32 | 33 | 8 34 | 00:00:20,210 --> 00:00:23,080 35 | The credit card number is 36 | of data type long_long, 37 | 38 | 9 39 | 00:00:23,080 --> 00:00:27,190 40 | so the CS50 library function 41 | get_long_long will be quite useful. 42 | 43 | 10 44 | 00:00:27,190 --> 00:00:30,690 45 | But this function ensures that 46 | the user inputs any integer. 47 | 48 | 11 49 | 00:00:30,690 --> 00:00:34,730 50 | So any positive integers, negative 51 | integers, or zero is all fine. 52 | 53 | 12 54 | 00:00:34,730 --> 00:00:37,560 55 | So up to you to further 56 | validate whether or not 57 | 58 | 13 59 | 00:00:37,560 --> 00:00:41,770 60 | the user has given us a valid 61 | credit card type number. 62 | 63 | 14 64 | 00:00:41,770 --> 00:00:44,560 65 | >> Now that we have a credit card 66 | number from the user, then 67 | 68 | 15 69 | 00:00:44,560 --> 00:00:46,580 70 | we need to calculate the checksum. 71 | 72 | 16 73 | 00:00:46,580 --> 00:00:49,780 74 | So credit card checksums 75 | are calculated as follows. 76 | 77 | 17 78 | 00:00:49,780 --> 00:00:54,370 79 | Starting from the second to last digit, 80 | we multiply every other digit by 2. 81 | 82 | 18 83 | 00:00:54,370 --> 00:00:57,060 84 | Then we add those 85 | products' digits together. 86 | 87 | 19 88 | 00:00:57,060 --> 00:01:00,140 89 | From that we add the 90 | sum of the digits that 91 | 92 | 20 93 | 00:01:00,140 --> 00:01:03,780 94 | weren't multiplied by 2 to that 95 | previous sum that we calculated. 96 | 97 | 21 98 | 00:01:03,780 --> 00:01:08,480 99 | Finally, if that number ends 100 | in 0, then the number is valid. 101 | 102 | 22 103 | 00:01:08,480 --> 00:01:11,760 104 | >> Let's go through an example 105 | and take this step by step. 106 | 107 | 23 108 | 00:01:11,760 --> 00:01:14,930 109 | So our first step is to start 110 | from the second to last digit 111 | 112 | 24 113 | 00:01:14,930 --> 00:01:18,080 114 | and multiply every other digit by two. 115 | 116 | 25 117 | 00:01:18,080 --> 00:01:22,240 118 | Now, if I stored the credit card 119 | number in a variable called CC number, 120 | 121 | 26 122 | 00:01:22,240 --> 00:01:26,060 123 | then modding that by 10 would 124 | give me the very last digit. 125 | 126 | 27 127 | 00:01:26,060 --> 00:01:28,910 128 | So how might you access 129 | the second to last digit? 130 | 131 | 28 132 | 00:01:28,910 --> 00:01:32,030 133 | >> OK, so once we've accessed 134 | the second to last digit, 135 | 136 | 29 137 | 00:01:32,030 --> 00:01:35,790 138 | then we'll iterate through 139 | multiplying every other digit by 2. 140 | 141 | 30 142 | 00:01:35,790 --> 00:01:38,620 143 | Once we have that, then 144 | we'll take those products 145 | 146 | 31 147 | 00:01:38,620 --> 00:01:41,350 148 | and add those products' digits together. 149 | 150 | 32 151 | 00:01:41,350 --> 00:01:43,830 152 | So here I have single 153 | digits, so that's fine. 154 | 155 | 33 156 | 00:01:43,830 --> 00:01:47,480 157 | But then once I get to my last 158 | number-- 7 multiplied by 2-- 159 | 160 | 34 161 | 00:01:47,480 --> 00:01:52,080 162 | I add the 1 and the 4 to give me 27. 163 | 164 | 35 165 | 00:01:52,080 --> 00:01:55,980 166 | From there, we add that product-- 167 | 27-- to the sum of the digits that 168 | 169 | 36 170 | 00:01:55,980 --> 00:01:57,790 171 | weren't multiplied by 2. 172 | 173 | 37 174 | 00:01:57,790 --> 00:02:01,070 175 | >> So here I've highlighted all 176 | of those numbers in orange. 177 | 178 | 38 179 | 00:02:01,070 --> 00:02:04,900 180 | Once we add those digits, then 181 | we get our final checksum number. 182 | 183 | 39 184 | 00:02:04,900 --> 00:02:09,120 185 | So we validate it by making 186 | sure that the last digit is 0. 187 | 188 | 40 189 | 00:02:09,120 --> 00:02:12,635 190 | If the checksum does not end in 191 | 0, then the credit card number 192 | 193 | 41 194 | 00:02:12,635 --> 00:02:14,400 195 | is definitely invalid. 196 | 197 | 42 198 | 00:02:14,400 --> 00:02:17,840 199 | Otherwise, let's go on to 200 | check the company identifiers 201 | 202 | 43 203 | 00:02:17,840 --> 00:02:19,870 204 | and the credit card number length. 205 | 206 | 44 207 | 00:02:19,870 --> 00:02:21,830 208 | >> We've provided a list 209 | of three companies, 210 | 211 | 45 212 | 00:02:21,830 --> 00:02:25,940 213 | along with that, the number of integers 214 | that their credit card numbers have. 215 | 216 | 46 217 | 00:02:25,940 --> 00:02:29,630 218 | Then the first two digits that 219 | those cards might start with. 220 | 221 | 47 222 | 00:02:29,630 --> 00:02:34,070 223 | So up to you to keep track of the 224 | first two digits of the credit card 225 | 226 | 48 227 | 00:02:34,070 --> 00:02:37,620 228 | and the number of integers in that card. 229 | 230 | 49 231 | 00:02:37,620 --> 00:02:40,110 232 | And with that, you've 233 | finished the problem. 234 | 235 | 50 236 | 00:02:40,110 --> 00:02:44,210 237 | My name is Zamyla, and this was Credit. 238 | 239 | 51 240 | 00:02:44,210 --> 00:02:45,859 241 | -------------------------------------------------------------------------------- /2016/en/walkthroughs/fifteen.srt: -------------------------------------------------------------------------------- 1 | 1 2 | 00:00:00,000 --> 00:00:00,499 3 | 4 | 5 | 2 6 | 00:00:00,499 --> 00:00:02,090 7 | ZAMYLA CHAN: Let's play a game. 8 | 9 | 3 10 | 00:00:02,090 --> 00:00:04,860 11 | In the game of fifteen, 12 | we have a tile set 13 | 14 | 4 15 | 00:00:04,860 --> 00:00:07,220 16 | that we allow the user 17 | to move around the tiles 18 | 19 | 5 20 | 00:00:07,220 --> 00:00:10,630 21 | until the numbers are 22 | arranged in the correct order. 23 | 24 | 6 25 | 00:00:10,630 --> 00:00:11,870 26 | How do we do this? 27 | 28 | 7 29 | 00:00:11,870 --> 00:00:13,510 30 | The game is a little involved. 31 | 32 | 8 33 | 00:00:13,510 --> 00:00:17,890 34 | So in fifteen.c, you'll find 35 | a lot of distribution code. 36 | 37 | 9 38 | 00:00:17,890 --> 00:00:22,280 39 | In that distribution code, it accepts 40 | and parses the command-line arguments, 41 | 42 | 10 43 | 00:00:22,280 --> 00:00:25,920 44 | creates the board, and 45 | then enters the game play 46 | 47 | 11 48 | 00:00:25,920 --> 00:00:30,130 49 | by checking to see where the game is 50 | won and exiting if it is, and otherwise, 51 | 52 | 12 53 | 00:00:30,130 --> 00:00:33,680 54 | getting input from the user to 55 | see which tile should be moved, 56 | 57 | 13 58 | 00:00:33,680 --> 00:00:35,610 59 | and calling that function. 60 | 61 | 14 62 | 00:00:35,610 --> 00:00:37,720 63 | So what do we actually have to do? 64 | 65 | 15 66 | 00:00:37,720 --> 00:00:41,610 67 | Well, within fifteen.c, you'll 68 | find calls to four functions-- 69 | 70 | 16 71 | 00:00:41,610 --> 00:00:44,710 72 | init, draw, move, and won. 73 | 74 | 17 75 | 00:00:44,710 --> 00:00:47,240 76 | And that's our job to implement. 77 | 78 | 18 79 | 00:00:47,240 --> 00:00:51,640 80 | Init stands for initialize, where 81 | we initialize the 2D integer 82 | 83 | 19 84 | 00:00:51,640 --> 00:00:54,460 85 | array that will represent our board. 86 | 87 | 20 88 | 00:00:54,460 --> 00:00:57,460 89 | Now, this board is going 90 | to be of dimensions d, 91 | 92 | 21 93 | 00:00:57,460 --> 00:01:02,870 94 | given by the user, where that dimension 95 | is less than the game's given maximum. 96 | 97 | 22 98 | 00:01:02,870 --> 00:01:07,099 99 | We've encountered 1D arrays 100 | already, so what are 2D arrays? 101 | 102 | 23 103 | 00:01:07,099 --> 00:01:08,640 104 | Well, they're not all that different. 105 | 106 | 24 107 | 00:01:08,640 --> 00:01:11,770 108 | We can just represent 109 | 2D arrays as grids. 110 | 111 | 25 112 | 00:01:11,770 --> 00:01:15,220 113 | Here, I've initialized a 114 | new 2D array called grid. 115 | 116 | 26 117 | 00:01:15,220 --> 00:01:18,860 118 | You'll see that I put two indicators 119 | for the dimension, as opposed 120 | 121 | 27 122 | 00:01:18,860 --> 00:01:21,000 123 | to one in a one-dimensional array. 124 | 125 | 28 126 | 00:01:21,000 --> 00:01:24,120 127 | So I'm going to declare every 128 | single element of this grid 129 | 130 | 29 131 | 00:01:24,120 --> 00:01:31,610 132 | explicitly, where grid 0, 0 is 8, 133 | and grid 0, 1 is 7, grid 0, 2 is 6. 134 | 135 | 30 136 | 00:01:31,610 --> 00:01:34,990 137 | You'll see that the indicator 138 | for the row comes first, 139 | 140 | 31 141 | 00:01:34,990 --> 00:01:37,590 142 | and then the index for 143 | the column comes second. 144 | 145 | 32 146 | 00:01:37,590 --> 00:01:40,710 147 | So now proceeding to the next 148 | row, then the first index 149 | 150 | 33 151 | 00:01:40,710 --> 00:01:43,570 152 | in all of my declarations 153 | is going to be 1. 154 | 155 | 34 156 | 00:01:43,570 --> 00:01:49,840 157 | So indeed, we have grid at 1, 0 158 | set as 5, grid at 1, 1 set as 4, 159 | 160 | 35 161 | 00:01:49,840 --> 00:01:52,950 162 | and grid at 1, 2 set to 3. 163 | 164 | 36 165 | 00:01:52,950 --> 00:01:58,600 166 | Moving on to the last row, I have grid 167 | at 2, 0 equal to 2, and grid at 2, 168 | 169 | 37 170 | 00:01:58,600 --> 00:02:00,600 171 | 1 equal to 1. 172 | 173 | 38 174 | 00:02:00,600 --> 00:02:03,170 175 | Now, in the physical version 176 | of the game of fifteen, 177 | 178 | 39 179 | 00:02:03,170 --> 00:02:07,910 180 | it's actually made up of tiles, whereby 181 | the player moves those tiles around 182 | 183 | 40 184 | 00:02:07,910 --> 00:02:12,830 185 | in order to move the tiles 186 | into correct descending order. 187 | 188 | 41 189 | 00:02:12,830 --> 00:02:16,160 190 | So in our digital version 191 | of the game of fifteen, 192 | 193 | 42 194 | 00:02:16,160 --> 00:02:19,430 195 | we also want a blank 196 | space for that user. 197 | 198 | 43 199 | 00:02:19,430 --> 00:02:22,190 200 | So we're not going to 201 | display a number there. 202 | 203 | 44 204 | 00:02:22,190 --> 00:02:26,370 205 | But knowing that this is an integer 206 | grid, we have to put an integer there. 207 | 208 | 45 209 | 00:02:26,370 --> 00:02:28,150 210 | But we're not going to display it. 211 | 212 | 46 213 | 00:02:28,150 --> 00:02:31,780 214 | So it's up to you to choose which 215 | one makes most sense to you. 216 | 217 | 47 218 | 00:02:31,780 --> 00:02:36,520 219 | So to recap, for initialize, we want 220 | to initialize the board, a 2D integer 221 | 222 | 48 223 | 00:02:36,520 --> 00:02:39,760 224 | array, with the starting state 225 | of the game of fifteen board, 226 | 227 | 49 228 | 00:02:39,760 --> 00:02:45,320 229 | where board at index i, j represents 230 | the tile at row i and column j, 231 | 232 | 50 233 | 00:02:45,320 --> 00:02:49,330 234 | and the numbers for these tiles start 235 | in descending order-- left to right, top 236 | 237 | 51 238 | 00:02:49,330 --> 00:02:50,250 239 | to bottom. 240 | 241 | 52 242 | 00:02:50,250 --> 00:02:52,450 243 | So what does the pseudocode look like? 244 | 245 | 53 246 | 00:02:52,450 --> 00:02:57,380 247 | Well, to iterate over the entire grid, 248 | then for each row and each column, 249 | 250 | 54 251 | 00:02:57,380 --> 00:03:00,020 252 | we want to set the value for the tile. 253 | 254 | 55 255 | 00:03:00,020 --> 00:03:03,090 256 | It might look something like 257 | this-- a nested for loop. 258 | 259 | 56 260 | 00:03:03,090 --> 00:03:07,040 261 | Here, integer i iterates 262 | over the rows, and integer j 263 | 264 | 57 265 | 00:03:07,040 --> 00:03:08,730 266 | iterates over the columns. 267 | 268 | 58 269 | 00:03:08,730 --> 00:03:11,710 270 | And within that, we 271 | set the tile's value. 272 | 273 | 59 274 | 00:03:11,710 --> 00:03:14,630 275 | Now, unfortunately, it's 276 | not quite so simple. 277 | 278 | 60 279 | 00:03:14,630 --> 00:03:17,780 280 | In order for the game of fifteen 281 | to be completely winnable, 282 | 283 | 61 284 | 00:03:17,780 --> 00:03:20,760 285 | then there are certain 286 | cases with certain numbers 287 | 288 | 62 289 | 00:03:20,760 --> 00:03:26,230 290 | of tiles when you actually have to 291 | swap the 2 tile with the 1 tile. 292 | 293 | 63 294 | 00:03:26,230 --> 00:03:32,250 295 | The rule is that whenever the 296 | dimension, d, is even, you swap 2 and 1. 297 | 298 | 64 299 | 00:03:32,250 --> 00:03:36,140 300 | So in the case that we already 301 | talked about with d being 3, 302 | 303 | 65 304 | 00:03:36,140 --> 00:03:37,640 305 | we don't need to worry about that. 306 | 307 | 66 308 | 00:03:37,640 --> 00:03:40,240 309 | But when d is 4, for 310 | instance, then we actually 311 | 312 | 67 313 | 00:03:40,240 --> 00:03:43,060 314 | have to switch the 1 and the 2 tile. 315 | 316 | 68 317 | 00:03:43,060 --> 00:03:48,940 318 | So make sure you include a case in 319 | order to check whether d is even or not. 320 | 321 | 69 322 | 00:03:48,940 --> 00:03:50,100 323 | I'll give you a hint. 324 | 325 | 70 326 | 00:03:50,100 --> 00:03:53,430 327 | Modulo might come in handy. 328 | 329 | 71 330 | 00:03:53,430 --> 00:03:57,910 331 | Now that we've initialized our board, 332 | it's time to go on to drawing it. 333 | 334 | 72 335 | 00:03:57,910 --> 00:04:01,870 336 | Now, if we follow the same pattern as 337 | we did when we initialized the board, 338 | 339 | 73 340 | 00:04:01,870 --> 00:04:06,420 341 | then we'll iterate over the board in the 342 | same exact order as we initialized it. 343 | 344 | 74 345 | 00:04:06,420 --> 00:04:09,900 346 | So let's iterate over the rows 347 | first, and then the columns, 348 | 349 | 75 350 | 00:04:09,900 --> 00:04:12,210 351 | and then print the tile's value. 352 | 353 | 76 354 | 00:04:12,210 --> 00:04:14,360 355 | Now, since this is a 356 | visual game, we want 357 | 358 | 77 359 | 00:04:14,360 --> 00:04:18,390 360 | to make sure that the users can sort 361 | of see where the tiles end and begin, 362 | 363 | 78 364 | 00:04:18,390 --> 00:04:20,140 365 | and when the rows end and begin. 366 | 367 | 79 368 | 00:04:20,140 --> 00:04:23,230 369 | So let's print a new line and 370 | perhaps some other characters 371 | 372 | 80 373 | 00:04:23,230 --> 00:04:26,682 374 | to indicate when tiles 375 | and rows begin and end. 376 | 377 | 81 378 | 00:04:26,682 --> 00:04:28,640 379 | We're almost done with 380 | the draw function, which 381 | 382 | 82 383 | 00:04:28,640 --> 00:04:30,348 384 | will print the current 385 | state of the board 386 | 387 | 83 388 | 00:04:30,348 --> 00:04:32,280 389 | whenever the draw function is called. 390 | 391 | 84 392 | 00:04:32,280 --> 00:04:34,680 393 | All that's left is to 394 | ensure proper formatting. 395 | 396 | 85 397 | 00:04:34,680 --> 00:04:37,520 398 | So for this, we'd like 399 | you to print a blank space 400 | 401 | 86 402 | 00:04:37,520 --> 00:04:39,370 403 | before any single-digit numbers. 404 | 405 | 87 406 | 00:04:39,370 --> 00:04:42,160 407 | That way, single-dingle numbers 408 | and double-digit numbers 409 | 410 | 88 411 | 00:04:42,160 --> 00:04:44,060 412 | will look the same. 413 | 414 | 89 415 | 00:04:44,060 --> 00:04:47,740 416 | For this, all you have to do is 417 | modify your original printf statement 418 | 419 | 90 420 | 00:04:47,740 --> 00:04:52,930 421 | for printing an integer, except 422 | instead of a %i, let's add a %2i. 423 | 424 | 91 425 | 00:04:52,930 --> 00:04:55,690 426 | That way, we'll ensure 427 | that a space is printed 428 | 429 | 92 430 | 00:04:55,690 --> 00:04:59,980 431 | before any single-digit numbers, 432 | and no space before a double digit. 433 | 434 | 93 435 | 00:04:59,980 --> 00:05:02,870 436 | Then the very last thing 437 | to do in this draw function 438 | 439 | 94 440 | 00:05:02,870 --> 00:05:07,730 441 | is to make sure that the user can 442 | visually see where the blank tile is. 443 | 444 | 95 445 | 00:05:07,730 --> 00:05:10,560 446 | For this, we're representing 447 | it with an underscore. 448 | 449 | 96 450 | 00:05:10,560 --> 00:05:13,060 451 | The board is a 2D array of integers. 452 | 453 | 97 454 | 00:05:13,060 --> 00:05:15,860 455 | And an underscore 456 | definitely isn't an integer. 457 | 458 | 98 459 | 00:05:15,860 --> 00:05:18,210 460 | So how do you reconcile the two? 461 | 462 | 99 463 | 00:05:18,210 --> 00:05:21,180 464 | Well, I propose that as you're 465 | iterating over your board 466 | 467 | 100 468 | 00:05:21,180 --> 00:05:24,350 469 | and printing those values, 470 | you include a condition where 471 | 472 | 101 473 | 00:05:24,350 --> 00:05:28,550 474 | you make sure to print an underscore 475 | on lieu of whatever other integer you 476 | 477 | 102 478 | 00:05:28,550 --> 00:05:32,290 479 | stored in that blank tile location. 480 | 481 | 103 482 | 00:05:32,290 --> 00:05:36,800 483 | So now that we've drawn our 484 | board, it's time to move it. 485 | 486 | 104 487 | 00:05:36,800 --> 00:05:39,320 488 | In move, you want to 489 | implement the functionality 490 | 491 | 105 492 | 00:05:39,320 --> 00:05:44,290 493 | where the user has already given you 494 | the tile number, not the tile location. 495 | 496 | 106 497 | 00:05:44,290 --> 00:05:47,810 498 | So your first job is to 499 | find that tile location. 500 | 501 | 107 502 | 00:05:47,810 --> 00:05:52,080 503 | Try to see if you can do this 504 | in a nice, iterative manner. 505 | 506 | 108 507 | 00:05:52,080 --> 00:05:56,130 508 | So then next, we want to edit the 509 | board array to move that tile, 510 | 511 | 109 512 | 00:05:56,130 --> 00:05:58,320 513 | but only if the move is legal. 514 | 515 | 110 516 | 00:05:58,320 --> 00:06:00,770 517 | A legal move in the game 518 | of fifteen is to move 519 | 520 | 111 521 | 00:06:00,770 --> 00:06:03,020 522 | any tile that's above, 523 | below, to the left, 524 | 525 | 112 526 | 00:06:03,020 --> 00:06:05,530 527 | or to the right of the blank tile. 528 | 529 | 113 530 | 00:06:05,530 --> 00:06:09,820 531 | So in this case, the 8, the 5, and 532 | the 2 are all legal tiles to move, 533 | 534 | 114 535 | 00:06:09,820 --> 00:06:12,730 536 | but not the 7, because that 537 | one's diagonal to the blank. 538 | 539 | 115 540 | 00:06:12,730 --> 00:06:16,610 541 | Once we found that, we swap 542 | the tile and the blank tile. 543 | 544 | 116 545 | 00:06:16,610 --> 00:06:20,270 546 | So even though we searched 547 | for that 8 tile before, 548 | 549 | 117 550 | 00:06:20,270 --> 00:06:22,770 551 | we're always going to 552 | need that blank tile. 553 | 554 | 118 555 | 00:06:22,770 --> 00:06:26,690 556 | So I suggest that you keep 557 | track of where the blank is 558 | 559 | 119 560 | 00:06:26,690 --> 00:06:29,680 561 | using two nicely named variables. 562 | 563 | 120 564 | 00:06:29,680 --> 00:06:30,440 565 | Great. 566 | 567 | 121 568 | 00:06:30,440 --> 00:06:34,120 569 | So now the user can 570 | move any valid tiles. 571 | 572 | 122 573 | 00:06:34,120 --> 00:06:38,960 574 | The last thing to do is to check to 575 | see whether they've won the game. 576 | 577 | 123 578 | 00:06:38,960 --> 00:06:42,360 579 | The fifteen.c file calls won. 580 | 581 | 124 582 | 00:06:42,360 --> 00:06:46,380 583 | And won returns true if the game 584 | is won, and false otherwise. 585 | 586 | 125 587 | 00:06:46,380 --> 00:06:48,550 588 | The rule for the game 589 | of 15 is that the game 590 | 591 | 126 592 | 00:06:48,550 --> 00:06:53,490 593 | is won when the tiles are in increasing 594 | order left to right, top to bottom. 595 | 596 | 127 597 | 00:06:53,490 --> 00:06:55,310 598 | So how do we check this? 599 | 600 | 128 601 | 00:06:55,310 --> 00:06:59,130 602 | Well, let's iterate over the 603 | board and check each value. 604 | 605 | 129 606 | 00:06:59,130 --> 00:07:02,200 607 | And if any value is incorrect, 608 | then we'll return false. 609 | 610 | 130 611 | 00:07:02,200 --> 00:07:04,770 612 | And then the user has to 613 | keep on playing the game. 614 | 615 | 131 616 | 00:07:04,770 --> 00:07:08,890 617 | But once we've checked all the 618 | values, then we'll return true. 619 | 620 | 132 621 | 00:07:08,890 --> 00:07:11,590 622 | The user has won, and so 623 | have you, because you've 624 | 625 | 133 626 | 00:07:11,590 --> 00:07:13,970 627 | completed the game of fifteen. 628 | 629 | 134 630 | 00:07:13,970 --> 00:07:18,190 631 | My name is Zamyla, and this was fifteen. 632 | 633 | 135 634 | 00:07:18,190 --> 00:07:19,808 -------------------------------------------------------------------------------- /2016/en/walkthroughs/hello.srt: -------------------------------------------------------------------------------- 1 | 1 2 | 00:00:00,000 --> 00:00:00,500 3 | 4 | 2 5 | 00:00:00,500 --> 00:00:01,590 6 | ZAMYLA CHAN: Hello, world. 7 | 8 | 3 9 | 00:00:01,590 --> 00:00:02,570 10 | My name is Zamyla. 11 | 12 | 4 13 | 00:00:02,570 --> 00:00:06,670 14 | And I will be your walk-through 15 | lead for these CS50 problems. 16 | 17 | 5 18 | 00:00:06,670 --> 00:00:10,160 19 | In each walk-through, I'll go for 20 | what's required for the problem, 21 | 22 | 6 23 | 00:00:10,160 --> 00:00:13,360 24 | I'll go over what the 25 | list of to-dos are, 26 | 27 | 7 28 | 00:00:13,360 --> 00:00:17,840 29 | and I'll provide more of a high-level, 30 | algorithmic way of getting started, 31 | 32 | 8 33 | 00:00:17,840 --> 00:00:20,050 34 | give you a few hints, 35 | a few snippets of code. 36 | 37 | 9 38 | 00:00:20,050 --> 00:00:24,350 39 | And hopefully, you'll be well on 40 | your way to completing the problem. 41 | 42 | 10 43 | 00:00:24,350 --> 00:00:26,860 44 | >> So for today, let's 45 | talk about hello, where 46 | 47 | 11 48 | 00:00:26,860 --> 00:00:29,930 49 | we're going to write our 50 | very first C program. 51 | 52 | 12 53 | 00:00:29,930 --> 00:00:33,070 54 | What we need to do is first 55 | navigate to our workspace, 56 | 57 | 13 58 | 00:00:33,070 --> 00:00:38,530 59 | where we're going to create a 60 | file and save it as hello.c. 61 | 62 | 14 63 | 00:00:38,530 --> 00:00:41,220 64 | I've already written 65 | a bit of code already. 66 | 67 | 15 68 | 00:00:41,220 --> 00:00:44,060 69 | I've included the standard 70 | io library, and then 71 | 72 | 16 73 | 00:00:44,060 --> 00:00:46,760 74 | I just created my main function. 75 | 76 | 17 77 | 00:00:46,760 --> 00:00:53,410 78 | >> What I'm going to do is I'm going 79 | to write printf Hello, world! 80 | 81 | 18 82 | 00:00:53,410 --> 00:00:57,710 83 | with a backslash n for a nice, 84 | new [INAUDIBLE] formatting, 85 | 86 | 19 87 | 00:00:57,710 --> 00:00:59,910 88 | and a semicolon to end. 89 | 90 | 20 91 | 00:00:59,910 --> 00:01:02,260 92 | After saving our program, 93 | let's go to our terminal, 94 | 95 | 21 96 | 00:01:02,260 --> 00:01:07,430 97 | where we're going to compile it 98 | by typing the command make hello. 99 | 100 | 22 101 | 00:01:07,430 --> 00:01:08,590 102 | It compiles correctly. 103 | 104 | 23 105 | 00:01:08,590 --> 00:01:13,550 106 | And so we can go ahead and run 107 | our executable file ./hello. 108 | 109 | 24 110 | 00:01:13,550 --> 00:01:15,900 111 | >> And there we get Hello, world! 112 | 113 | 25 114 | 00:01:15,900 --> 00:01:16,880 115 | Hello, world! 116 | 117 | 26 118 | 00:01:16,880 --> 00:01:20,910 119 | My name is Zamyla, and this was hello. 120 | 121 | 27 122 | 00:01:20,910 --> 00:01:22,151 123 | -------------------------------------------------------------------------------- /2016/en/walkthroughs/initials_less.srt: -------------------------------------------------------------------------------- 1 | 1 2 | 00:00:00,000 --> 00:00:00,460 3 | 4 | 2 5 | 00:00:00,460 --> 00:00:02,251 6 | >> ZAMYLA CHAN: In the 7 | initials problem, we're 8 | 9 | 3 10 | 00:00:02,251 --> 00:00:04,320 11 | going to prompt the user 12 | for their name and then 13 | 14 | 4 15 | 00:00:04,320 --> 00:00:07,000 16 | print the initials from that name. 17 | 18 | 5 19 | 00:00:07,000 --> 00:00:09,750 20 | To prompt the user for the name, 21 | we'll use the get_string function 22 | 23 | 6 24 | 00:00:09,750 --> 00:00:11,670 25 | found in the CS 50 library. 26 | 27 | 7 28 | 00:00:11,670 --> 00:00:14,000 29 | >> You're allowed to make 30 | two assumptions-- one, 31 | 32 | 8 33 | 00:00:14,000 --> 00:00:17,010 34 | that the string will be comprised 35 | of only letters and spaces-- so 36 | 37 | 9 38 | 00:00:17,010 --> 00:00:19,152 39 | no numbers, no other characters. 40 | 41 | 10 42 | 00:00:19,152 --> 00:00:21,110 43 | You're also allowed to 44 | assume that there's only 45 | 46 | 11 47 | 00:00:21,110 --> 00:00:25,420 48 | going to be a single space 49 | between letters, between names. 50 | 51 | 12 52 | 00:00:25,420 --> 00:00:29,560 53 | >> So once you have that string, then 54 | let's go to print the initials. 55 | 56 | 13 57 | 00:00:29,560 --> 00:00:32,740 58 | In this example, say I 59 | were to be a perfect user. 60 | 61 | 14 62 | 00:00:32,740 --> 00:00:36,040 63 | Then I'd type in my name with 64 | a capital Z and a capital C, 65 | 66 | 15 67 | 00:00:36,040 --> 00:00:37,940 68 | with a single space in between. 69 | 70 | 16 71 | 00:00:37,940 --> 00:00:40,360 72 | So your program would 73 | calculate the first letter 74 | 75 | 17 76 | 00:00:40,360 --> 00:00:44,860 77 | and then the first letter after 78 | a space, and print out ZC. 79 | 80 | 18 81 | 00:00:44,860 --> 00:00:47,710 82 | >> But for instance, say Mile 83 | Banana is at the keyboard. 84 | 85 | 19 86 | 00:00:47,710 --> 00:00:50,240 87 | Well, he might be a 88 | little bit sloppier than I 89 | 90 | 20 91 | 00:00:50,240 --> 00:00:54,890 92 | am and only type in lowercase 93 | letters and include an extra space 94 | 95 | 21 96 | 00:00:54,890 --> 00:00:56,870 97 | in front of his first name. 98 | 99 | 22 100 | 00:00:56,870 --> 00:00:59,890 101 | But your program should 102 | have the same exact output, 103 | 104 | 23 105 | 00:00:59,890 --> 00:01:03,440 106 | with a capital MB without any spaces. 107 | 108 | 24 109 | 00:01:03,440 --> 00:01:06,600 110 | >> Finally, whenever you've 111 | determined the characters to print, 112 | 113 | 25 114 | 00:01:06,600 --> 00:01:11,360 115 | make sure that you print them as 116 | uppercase using the toupper function. 117 | 118 | 26 119 | 00:01:11,360 --> 00:01:15,870 120 | >> My name is ZC, and this was initials. 121 | 122 | 27 123 | 00:01:15,870 --> 00:01:18,482 124 | -------------------------------------------------------------------------------- /2016/en/walkthroughs/initials_more.srt: -------------------------------------------------------------------------------- 1 | 1 2 | 00:00:00,000 --> 00:00:00,399 3 | 4 | 2 5 | 00:00:00,399 --> 00:00:02,190 6 | ZAMYLA CHAN: In the 7 | initials problem, we're 8 | 9 | 3 10 | 00:00:02,190 --> 00:00:05,650 11 | going to prompt the user for their 12 | name and then print their initials. 13 | 14 | 4 15 | 00:00:05,650 --> 00:00:09,010 16 | To prompt for the name, we'll use the 17 | get string function found in the CS 50 18 | 19 | 5 20 | 00:00:09,010 --> 00:00:12,090 21 | library, and you're allowed to 22 | assume that this string will only 23 | 24 | 6 25 | 00:00:12,090 --> 00:00:17,490 26 | contain letters and spaces-- so no 27 | numbers and no other characters. 28 | 29 | 7 30 | 00:00:17,490 --> 00:00:21,250 31 | Then, once you have the 32 | string, you'll iterate through. 33 | 34 | 8 35 | 00:00:21,250 --> 00:00:23,520 36 | >> If, say, I was using 37 | this program, then I 38 | 39 | 9 40 | 00:00:23,520 --> 00:00:26,790 41 | might type my name perfectly-- 42 | Zamyla Chan with a capital Z 43 | 44 | 10 45 | 00:00:26,790 --> 00:00:30,510 46 | in the beginning, a space, and then 47 | a capital C to start my last name. 48 | 49 | 11 50 | 00:00:30,510 --> 00:00:32,830 51 | So you'd simply iterate 52 | through the string, 53 | 54 | 12 55 | 00:00:32,830 --> 00:00:36,320 56 | getting the first character, and then 57 | the first character after a space 58 | 59 | 13 60 | 00:00:36,320 --> 00:00:38,120 61 | and printing those out. 62 | 63 | 14 64 | 00:00:38,120 --> 00:00:41,800 65 | >> But say you had a slightly 66 | sloppier user, Milo Banana, who 67 | 68 | 15 69 | 00:00:41,800 --> 00:00:45,420 70 | doesn't type in uppercase and 71 | might include some extraneous space 72 | 73 | 16 74 | 00:00:45,420 --> 00:00:46,380 75 | characters. 76 | 77 | 17 78 | 00:00:46,380 --> 00:00:48,752 79 | Well, then when you 80 | iterate through the string, 81 | 82 | 18 83 | 00:00:48,752 --> 00:00:51,710 84 | you'll have to check to make sure 85 | that you're not printing out a space, 86 | 87 | 19 88 | 00:00:51,710 --> 00:00:54,650 89 | but rather, his proper 90 | initials, capital M, 91 | 92 | 20 93 | 00:00:54,650 --> 00:00:59,330 94 | capital B. To print out capital letters, 95 | you can use the toupper function. 96 | 97 | 21 98 | 00:00:59,330 --> 00:01:01,710 99 | And with that, you finished the problem. 100 | 101 | 22 102 | 00:01:01,710 --> 00:01:06,119 103 | >> My name is Z. C., and this was initials. 104 | 105 | 23 106 | 00:01:06,119 --> 00:01:08,521 107 | -------------------------------------------------------------------------------- /2016/en/walkthroughs/mario_more.srt: -------------------------------------------------------------------------------- 1 | 1 2 | 00:00:00,000 --> 00:00:00,500 3 | 4 | 2 5 | 00:00:00,500 --> 00:00:02,640 6 | ZAMYLA CHAN: It's a-me, Zamyla. 7 | 8 | 3 9 | 00:00:02,640 --> 00:00:06,950 10 | Today, we're going to implement 11 | Mario, where we draw Mario 12 | 13 | 4 14 | 00:00:06,950 --> 00:00:10,730 15 | a full pyramid for him to jump over. 16 | 17 | 5 18 | 00:00:10,730 --> 00:00:14,430 19 | Let's break down the 20 | sub-tasks for this problem. 21 | 22 | 6 23 | 00:00:14,430 --> 00:00:17,930 24 | >> First, we want to prompt the user 25 | for the height of the pyramid. 26 | 27 | 7 28 | 00:00:17,930 --> 00:00:20,510 29 | And then we want to make sure 30 | that that input is valid. 31 | 32 | 8 33 | 00:00:20,510 --> 00:00:23,280 34 | And then we're going to 35 | want to draw the pyramid. 36 | 37 | 9 38 | 00:00:23,280 --> 00:00:26,850 39 | >> So let's talk about prompting 40 | and validating user input. 41 | 42 | 10 43 | 00:00:26,850 --> 00:00:29,920 44 | It might look something like 45 | this, a do-while loop that 46 | 47 | 11 48 | 00:00:29,920 --> 00:00:33,250 49 | prompts the user for an 50 | integer and then only repeats 51 | 52 | 12 53 | 00:00:33,250 --> 00:00:35,700 54 | if that integer is invalid. 55 | 56 | 13 57 | 00:00:35,700 --> 00:00:38,220 58 | So what should this condition be? 59 | 60 | 14 61 | 00:00:38,220 --> 00:00:40,630 62 | >> For this, let's go back 63 | to the specification. 64 | 65 | 15 66 | 00:00:40,630 --> 00:00:46,240 67 | Well, the spec tells us that any valid 68 | height is going to be between 0 and 23, 69 | 70 | 16 71 | 00:00:46,240 --> 00:00:47,350 72 | inclusive. 73 | 74 | 17 75 | 00:00:47,350 --> 00:00:51,400 76 | So then that means that any invalid 77 | height is going to be less than 0 78 | 79 | 18 80 | 00:00:51,400 --> 00:00:53,840 81 | or more than 23. 82 | 83 | 19 84 | 00:00:53,840 --> 00:00:57,220 85 | >> So now that we have this information, 86 | let's design our condition. 87 | 88 | 20 89 | 00:00:57,220 --> 00:00:59,230 90 | But we need to be careful, 91 | because now we have 92 | 93 | 21 94 | 00:00:59,230 --> 00:01:02,130 95 | two Booleans that we want to evaluate. 96 | 97 | 22 98 | 00:01:02,130 --> 00:01:04,150 99 | >> Here I've provided you 100 | with a truth table. 101 | 102 | 23 103 | 00:01:04,150 --> 00:01:07,520 104 | This allows us to take two 105 | Booleans, Boolean one and two. 106 | 107 | 24 108 | 00:01:07,520 --> 00:01:13,600 109 | And we can evaluate either bool1 110 | and bool2 or bool1 or bool2. 111 | 112 | 25 113 | 00:01:13,600 --> 00:01:17,390 114 | >> So what's the difference 115 | between and and or? 116 | 117 | 26 118 | 00:01:17,390 --> 00:01:21,810 119 | Well, bool1 and bool2 will 120 | evaluate to true if and only 121 | 122 | 27 123 | 00:01:21,810 --> 00:01:25,680 124 | if both Booleans are true, 125 | whereas the or operation 126 | 127 | 28 128 | 00:01:25,680 --> 00:01:30,190 129 | will be true if either one of 130 | the Booleans or both are true. 131 | 132 | 29 133 | 00:01:30,190 --> 00:01:33,110 134 | So with this in mind, 135 | see if you can figure out 136 | 137 | 30 138 | 00:01:33,110 --> 00:01:37,460 139 | what the appropriate condition for 140 | your do-while loop for an invalid n 141 | 142 | 31 143 | 00:01:37,460 --> 00:01:38,850 144 | is going to be. 145 | 146 | 32 147 | 00:01:38,850 --> 00:01:43,540 148 | >> With that, we've prompted and validated 149 | the user for the height of the pyramid 150 | 151 | 33 152 | 00:01:43,540 --> 00:01:44,550 153 | that they want. 154 | 155 | 34 156 | 00:01:44,550 --> 00:01:47,740 157 | So now, it's up to us 158 | to draw the pyramid. 159 | 160 | 35 161 | 00:01:47,740 --> 00:01:50,520 162 | The full pyramid for this 163 | problem will look a little bit 164 | 165 | 36 166 | 00:01:50,520 --> 00:01:56,340 167 | like this, where we have a left pyramid, 168 | some gap, and then a right pyramid. 169 | 170 | 37 171 | 00:01:56,340 --> 00:01:58,630 172 | So let's break this down a little bit. 173 | 174 | 38 175 | 00:01:58,630 --> 00:02:03,510 176 | >> If I go to my text editor, here I've 177 | drawn us a left-aligned pyramid. 178 | 179 | 39 180 | 00:02:03,510 --> 00:02:05,160 181 | But that won't do. 182 | 183 | 40 184 | 00:02:05,160 --> 00:02:10,139 185 | What we want to do is we want to 186 | create a right-aligned pyramid first. 187 | 188 | 41 189 | 00:02:10,139 --> 00:02:13,580 190 | So to do this, to just push 191 | my hashes along to the side, 192 | 193 | 42 194 | 00:02:13,580 --> 00:02:18,240 195 | I'm just going to put some characters 196 | in between, just these dots. 197 | 198 | 43 199 | 00:02:18,240 --> 00:02:22,560 200 | Then I'm going to put two on the 201 | next line, and one on that line. 202 | 203 | 44 204 | 00:02:22,560 --> 00:02:26,070 205 | And so here I have a 206 | right-aligned pyramid. 207 | 208 | 45 209 | 00:02:26,070 --> 00:02:28,540 210 | >> After that, I'm going to 211 | go back to the top row 212 | 213 | 46 214 | 00:02:28,540 --> 00:02:33,930 215 | and put in the gap, which 216 | is, per the spec, two spaces. 217 | 218 | 47 219 | 00:02:33,930 --> 00:02:37,680 220 | Then I'm going to fill in the 221 | other side of the pyramid. 222 | 223 | 48 224 | 00:02:37,680 --> 00:02:42,030 225 | I'm going to go to the second row, write 226 | two spaces for the gap and then two 227 | 228 | 49 229 | 00:02:42,030 --> 00:02:42,920 230 | hashes. 231 | 232 | 50 233 | 00:02:42,920 --> 00:02:47,020 234 | Back to the third row, two spaces 235 | for the gap and three hashes. 236 | 237 | 51 238 | 00:02:47,020 --> 00:02:51,480 239 | And at the end, two spaces 240 | for the gap and four hashes. 241 | 242 | 52 243 | 00:02:51,480 --> 00:02:54,400 244 | So that's what a full 245 | pyramid will look like. 246 | 247 | 53 248 | 00:02:54,400 --> 00:02:57,260 249 | >> Of course, we don't want 250 | these dots in the way. 251 | 252 | 54 253 | 00:02:57,260 --> 00:03:01,220 254 | So we're going to replace these 255 | dots by putting some spaces in. 256 | 257 | 55 258 | 00:03:01,220 --> 00:03:03,720 259 | One, two, three on the first line. 260 | 261 | 56 262 | 00:03:03,720 --> 00:03:05,650 263 | One, two on the second. 264 | 265 | 57 266 | 00:03:05,650 --> 00:03:08,200 267 | And one on the third line. 268 | 269 | 58 270 | 00:03:08,200 --> 00:03:12,060 271 | So this is what we would do if we 272 | wanted to just make a full pyramid, 273 | 274 | 59 275 | 00:03:12,060 --> 00:03:13,700 276 | say, in our text editor. 277 | 278 | 60 279 | 00:03:13,700 --> 00:03:15,860 280 | >> So let's take this, 281 | understanding the patterns, 282 | 283 | 61 284 | 00:03:15,860 --> 00:03:19,870 285 | and convert it over to some pseudocode. 286 | 287 | 62 288 | 00:03:19,870 --> 00:03:24,500 289 | For each row of the pyramid, we want 290 | to print the left pyramid and then 291 | 292 | 63 293 | 00:03:24,500 --> 00:03:26,580 294 | the gap and then the right pyramid. 295 | 296 | 64 297 | 00:03:26,580 --> 00:03:30,260 298 | For the left pyramid, we print 299 | the requisite amount of spaces, 300 | 301 | 65 302 | 00:03:30,260 --> 00:03:31,740 303 | followed by the hashes. 304 | 305 | 66 306 | 00:03:31,740 --> 00:03:35,030 307 | Then we print the gap, which 308 | is just two spaces every time. 309 | 310 | 67 311 | 00:03:35,030 --> 00:03:38,080 312 | And in the right pyramid, we print 313 | the requisite number of hashes. 314 | 315 | 68 316 | 00:03:38,080 --> 00:03:41,410 317 | >> For the second row, we conducted 318 | the same exact process. 319 | 320 | 69 321 | 00:03:41,410 --> 00:03:44,510 322 | We print the spaces for the left 323 | pyramid, the requisite amount 324 | 325 | 70 326 | 00:03:44,510 --> 00:03:49,930 327 | of hashes, the gap, two spaces, and 328 | then the hashes for the right pyramid. 329 | 330 | 71 331 | 00:03:49,930 --> 00:03:52,490 332 | >> Let's tackle the pattern 333 | for the left pyramid. 334 | 335 | 72 336 | 00:03:52,490 --> 00:03:55,660 337 | If I had, for purposes 338 | of this example, a height 339 | 340 | 73 341 | 00:03:55,660 --> 00:03:58,790 342 | of eight requested by the 343 | user, then my first row 344 | 345 | 74 346 | 00:03:58,790 --> 00:04:01,020 347 | would have one hash and seven spaces. 348 | 349 | 75 350 | 00:04:01,020 --> 00:04:03,860 351 | My second row would have 352 | two hashes, six spaces. 353 | 354 | 76 355 | 00:04:03,860 --> 00:04:06,749 356 | Third row, three hashes, five spaces. 357 | 358 | 77 359 | 00:04:06,749 --> 00:04:09,040 360 | You can probably do this 361 | yourself for a height of eight 362 | 363 | 78 364 | 00:04:09,040 --> 00:04:13,470 365 | and determine for each row how many 366 | hashes and how many spaces you need. 367 | 368 | 79 369 | 00:04:13,470 --> 00:04:16,209 370 | But what we want to do is 371 | we want to abstract it. 372 | 373 | 80 374 | 00:04:16,209 --> 00:04:22,660 375 | So I ask you for any nth row, how many 376 | hashes and how many spaces do we need? 377 | 378 | 81 379 | 00:04:22,660 --> 00:04:25,410 380 | >> Now, as you determine the 381 | pattern for how many hashes 382 | 383 | 82 384 | 00:04:25,410 --> 00:04:29,920 385 | and how many spaces you need for 386 | any nth row for a given height, 387 | 388 | 83 389 | 00:04:29,920 --> 00:04:32,910 390 | remember to be careful 391 | of how you're indexing. 392 | 393 | 84 394 | 00:04:32,910 --> 00:04:37,160 395 | What I mean by this is that in everyday 396 | life most of us start counting by one. 397 | 398 | 85 399 | 00:04:37,160 --> 00:04:39,680 400 | So the first row would be number one. 401 | 402 | 86 403 | 00:04:39,680 --> 00:04:43,620 404 | And the second row would be row 405 | number two, so on and so forth. 406 | 407 | 87 408 | 00:04:43,620 --> 00:04:47,620 409 | >> But in computer science and 410 | CS50, we are zero-indexed. 411 | 412 | 88 413 | 00:04:47,620 --> 00:04:50,750 414 | So we actually start counting at zero. 415 | 416 | 89 417 | 00:04:50,750 --> 00:04:54,020 418 | So the first row would 419 | be row number zero. 420 | 421 | 90 422 | 00:04:54,020 --> 00:04:56,640 423 | And the second row 424 | would be row number one. 425 | 426 | 91 427 | 00:04:56,640 --> 00:05:02,510 428 | So if I had a height of eight for 429 | my pyramid, then the last value of n 430 | 431 | 92 432 | 00:05:02,510 --> 00:05:05,850 433 | would actually be seven and not eight. 434 | 435 | 93 436 | 00:05:05,850 --> 00:05:07,010 437 | >> So be careful about this. 438 | 439 | 94 440 | 00:05:07,010 --> 00:05:10,750 441 | And be aware when you're determining 442 | your pattern whether your zero-indexed 443 | 444 | 95 445 | 00:05:10,750 --> 00:05:12,360 446 | or one-indexed 447 | 448 | 96 449 | 00:05:12,360 --> 00:05:13,070 450 | >> OK. 451 | 452 | 97 453 | 00:05:13,070 --> 00:05:15,380 454 | So now that we have the 455 | pattern for the left pyramid, 456 | 457 | 98 458 | 00:05:15,380 --> 00:05:18,650 459 | we need to determine 460 | the pattern for the gap. 461 | 462 | 99 463 | 00:05:18,650 --> 00:05:20,480 464 | Luckily, this is really easy. 465 | 466 | 100 467 | 00:05:20,480 --> 00:05:22,690 468 | It's just always two spaces. 469 | 470 | 101 471 | 00:05:22,690 --> 00:05:25,240 472 | >> So now we proceed to the right pattern. 473 | 474 | 102 475 | 00:05:25,240 --> 00:05:27,220 476 | The first row will have one hash. 477 | 478 | 103 479 | 00:05:27,220 --> 00:05:28,640 480 | The second row, two. 481 | 482 | 104 483 | 00:05:28,640 --> 00:05:29,530 484 | Third row, three. 485 | 486 | 105 487 | 00:05:29,530 --> 00:05:30,790 488 | So on and so forth. 489 | 490 | 106 491 | 00:05:30,790 --> 00:05:35,540 492 | So again, determine for any abstract 493 | n and any height how many hashes 494 | 495 | 107 496 | 00:05:35,540 --> 00:05:38,810 497 | and how many spaces 498 | each row should have. 499 | 500 | 108 501 | 00:05:38,810 --> 00:05:39,700 502 | >> OK. 503 | 504 | 109 505 | 00:05:39,700 --> 00:05:45,050 506 | So we know that for each row we 507 | need to conduct some process. 508 | 509 | 110 510 | 00:05:45,050 --> 00:05:46,600 511 | How do we do that? 512 | 513 | 111 514 | 00:05:46,600 --> 00:05:50,440 515 | Well, we use the for loop construct, 516 | comprised of an initialization, 517 | 518 | 112 519 | 00:05:50,440 --> 00:05:52,310 520 | a condition, and an update. 521 | 522 | 113 523 | 00:05:52,310 --> 00:05:54,830 524 | For loops can be used 525 | to repeat processes. 526 | 527 | 114 528 | 00:05:54,830 --> 00:05:59,610 529 | >> So say I want it to say hello, 530 | world 50 times, then my for loop 531 | 532 | 115 533 | 00:05:59,610 --> 00:06:03,510 534 | would look something like this, where 535 | I initialize my variable to zero. 536 | 537 | 116 538 | 00:06:03,510 --> 00:06:06,200 539 | The condition is that i is less than 50. 540 | 541 | 117 542 | 00:06:06,200 --> 00:06:09,670 543 | And then the update is that it 544 | increments by one every time. 545 | 546 | 118 547 | 00:06:09,670 --> 00:06:14,700 548 | So what this would do would be to 549 | print hello, world 50 times in a row. 550 | 551 | 119 552 | 00:06:14,700 --> 00:06:18,080 553 | >> Now, say I wanted to iterate 554 | over the height of the pyramid. 555 | 556 | 120 557 | 00:06:18,080 --> 00:06:21,560 558 | Then instead of hard coding 559 | some value in the condition, 560 | 561 | 121 562 | 00:06:21,560 --> 00:06:23,280 563 | I just use the variable height. 564 | 565 | 122 566 | 00:06:23,280 --> 00:06:27,180 567 | So what this will do is iterate 568 | over the height each row. 569 | 570 | 123 571 | 00:06:27,180 --> 00:06:30,280 572 | And I can do something inside 573 | of the body of that loop. 574 | 575 | 124 576 | 00:06:30,280 --> 00:06:32,710 577 | >> What do we want to do 578 | inside the body of the loop? 579 | 580 | 125 581 | 00:06:32,710 --> 00:06:36,550 582 | Well, as we indicated before, we want 583 | to print the spaces and the hashes 584 | 585 | 126 586 | 00:06:36,550 --> 00:06:40,730 587 | for the left pyramid and then print 588 | two spaces and then print the hashes. 589 | 590 | 127 591 | 00:06:40,730 --> 00:06:42,500 592 | So we've already figured that out. 593 | 594 | 128 595 | 00:06:42,500 --> 00:06:45,670 596 | So we can start to fill 597 | in our program a lot more. 598 | 599 | 129 600 | 00:06:45,670 --> 00:06:49,850 601 | >> Here I have an outer for loop that 602 | iterates over every row in the pyramid. 603 | 604 | 130 605 | 00:06:49,850 --> 00:06:53,340 606 | And inside that body I'm going 607 | to print spaces repeatedly, 608 | 609 | 131 610 | 00:06:53,340 --> 00:06:56,860 611 | hashes repeatedly, and then the gap, 612 | and then hashes for the right pyramid, 613 | 614 | 132 615 | 00:06:56,860 --> 00:07:00,440 616 | and then, finally, a new 617 | line to start the next row. 618 | 619 | 133 620 | 00:07:00,440 --> 00:07:02,860 621 | >> With that, we've prompted 622 | the user for the input. 623 | 624 | 134 625 | 00:07:02,860 --> 00:07:04,510 626 | We've made sure that it's valid. 627 | 628 | 135 629 | 00:07:04,510 --> 00:07:06,280 630 | And then we've drawn the pyramid. 631 | 632 | 136 633 | 00:07:06,280 --> 00:07:09,540 634 | So Mario can successfully 635 | climb the pyramid. 636 | 637 | 137 638 | 00:07:09,540 --> 00:07:10,970 639 | >> My name is Zamyla. 640 | 641 | 138 642 | 00:07:10,970 --> 00:07:13,840 643 | And this is CS50. 644 | 645 | 139 646 | 00:07:13,840 --> 00:07:15,419 647 | -------------------------------------------------------------------------------- /2016/en/walkthroughs/resize_more.srt: -------------------------------------------------------------------------------- 1 | 1 2 | 00:00:00,000 --> 00:00:00,500 3 | 4 | 5 | 2 6 | 00:00:00,500 --> 00:00:03,640 7 | ZAMYLA CHAN: Let's scale 8 | things up with resize. 9 | 10 | 3 11 | 00:00:03,640 --> 00:00:06,960 12 | In resize, the user will 13 | provide us with a float 14 | 15 | 4 16 | 00:00:06,960 --> 00:00:11,670 17 | by which they want to scale their infile 18 | and the name for an outfile image. 19 | 20 | 5 21 | 00:00:11,670 --> 00:00:15,280 22 | It's up to us to parse that float 23 | input, update the outfile's header 24 | 25 | 6 26 | 00:00:15,280 --> 00:00:18,620 27 | information, and then resize 28 | our bitmap accordingly, 29 | 30 | 7 31 | 00:00:18,620 --> 00:00:22,370 32 | either making it smaller 33 | or larger than before. 34 | 35 | 8 36 | 00:00:22,370 --> 00:00:24,630 37 | If we look at the 38 | distribution code, then we'll 39 | 40 | 9 41 | 00:00:24,630 --> 00:00:28,380 42 | see that the implementation 43 | of copy.c satisfies 44 | 45 | 10 46 | 00:00:28,380 --> 00:00:32,150 47 | a lot of similar functionalities 48 | to that of resize. 49 | 50 | 11 51 | 00:00:32,150 --> 00:00:36,270 52 | copy.c will parse an integer 53 | input, then open your infile 54 | 55 | 12 56 | 00:00:36,270 --> 00:00:39,640 57 | and outfile, updating the header 58 | information for your outfile 59 | 60 | 13 61 | 00:00:39,640 --> 00:00:42,260 62 | and reading into the 63 | infile scanline pixel 64 | 65 | 14 66 | 00:00:42,260 --> 00:00:46,300 67 | by pixel, writing those 68 | pixels into the output file. 69 | 70 | 15 71 | 00:00:46,300 --> 00:00:52,440 72 | So perhaps our first step would 73 | be to copy copy.c into resize.c. 74 | 75 | 16 76 | 00:00:52,440 --> 00:00:55,300 77 | But we need to parse 78 | floats not integers. 79 | 80 | 17 81 | 00:00:55,300 --> 00:00:58,820 82 | So check out the sscanf 83 | function and the atof function. 84 | 85 | 18 86 | 00:00:58,820 --> 00:01:01,910 87 | Also make sure to check 88 | out corner cases, perhaps 89 | 90 | 19 91 | 00:01:01,910 --> 00:01:07,360 92 | taking a peek into CS50's own get 93 | float function for more hints. 94 | 95 | 20 96 | 00:01:07,360 --> 00:01:10,870 97 | Then we need to update the 98 | outfile's header information. 99 | 100 | 21 101 | 00:01:10,870 --> 00:01:14,610 102 | Now, bitmaps are simply an arrangement 103 | of bytes just like any other file. 104 | 105 | 22 106 | 00:01:14,610 --> 00:01:17,610 107 | It's just a matter of how we 108 | interpret this arrangement. 109 | 110 | 23 111 | 00:01:17,610 --> 00:01:22,230 112 | So take a look into bmp.h 113 | for some documentation. 114 | 115 | 24 116 | 00:01:22,230 --> 00:01:24,410 117 | Essentially whenever 118 | we have a new bitmap, 119 | 120 | 25 121 | 00:01:24,410 --> 00:01:27,070 122 | we'll need to update 123 | the header information. 124 | 125 | 26 126 | 00:01:27,070 --> 00:01:30,620 127 | So what's changing when we're 128 | scaling up or scaling down? 129 | 130 | 27 131 | 00:01:30,620 --> 00:01:34,370 132 | Well, the file size is going to change 133 | as does the image size, the width, 134 | 135 | 28 136 | 00:01:34,370 --> 00:01:37,550 137 | and the height of our bitmap. 138 | 139 | 29 140 | 00:01:37,550 --> 00:01:40,250 141 | In the bitmap info header, 142 | we have the biWidth, 143 | 144 | 30 145 | 00:01:40,250 --> 00:01:43,280 146 | which includes the width of the 147 | image in pixels not including 148 | 149 | 31 150 | 00:01:43,280 --> 00:01:47,260 151 | padding, and the biHeight, the 152 | height of the image in pixels. 153 | 154 | 32 155 | 00:01:47,260 --> 00:01:51,560 156 | We also have the biSizeImage, which is 157 | the total size of the image in bytes 158 | 159 | 33 160 | 00:01:51,560 --> 00:01:54,860 161 | including the pixels and the padding. 162 | 163 | 34 164 | 00:01:54,860 --> 00:01:56,930 165 | Moving to the bitmap 166 | file header, we have 167 | 168 | 35 169 | 00:01:56,930 --> 00:02:00,890 170 | bfSize which contains the total 171 | size of the file in bytes. 172 | 173 | 36 174 | 00:02:00,890 --> 00:02:04,560 175 | So that includes pixels, 176 | padding, and the headers. 177 | 178 | 37 179 | 00:02:04,560 --> 00:02:08,410 180 | So of these values, what's changing 181 | when we scale our bitmap up or down 182 | 183 | 38 184 | 00:02:08,410 --> 00:02:09,860 185 | by a factor of f? 186 | 187 | 39 188 | 00:02:09,860 --> 00:02:13,310 189 | Well, biWidth and biHeight 190 | will definitely scale by f. 191 | 192 | 40 193 | 00:02:13,310 --> 00:02:18,700 194 | So figure out how biSizeImage and 195 | bfSize are also going to change. 196 | 197 | 41 198 | 00:02:18,700 --> 00:02:22,145 199 | Now that we've updated the outfile's 200 | header information, let's talk 201 | 202 | 42 203 | 00:02:22,145 --> 00:02:24,690 204 | about resizing horizontally. 205 | 206 | 43 207 | 00:02:24,690 --> 00:02:27,830 208 | So say the user gave us a float of 2. 209 | 210 | 44 211 | 00:02:27,830 --> 00:02:30,300 212 | Well then, the algorithm 213 | would be pretty simple. 214 | 215 | 45 216 | 00:02:30,300 --> 00:02:34,480 217 | For each pixel in the row, we 218 | would write that pixel f times 219 | 220 | 46 221 | 00:02:34,480 --> 00:02:36,290 222 | into the outfile row. 223 | 224 | 47 225 | 00:02:36,290 --> 00:02:43,460 226 | Now what if instead of a whole number 227 | float, the user gives us 1.5 or 0.5? 228 | 229 | 48 230 | 00:02:43,460 --> 00:02:47,210 231 | Well, it's impossible to write 232 | a pixel a fraction of a time. 233 | 234 | 49 235 | 00:02:47,210 --> 00:02:50,140 236 | So let's adjust our thinking. 237 | 238 | 50 239 | 00:02:50,140 --> 00:02:52,950 240 | Instead, how about for 241 | each pixel in the row, 242 | 243 | 51 244 | 00:02:52,950 --> 00:02:56,760 245 | we simply write the corresponding 246 | pixel from the old row? 247 | 248 | 52 249 | 00:02:56,760 --> 00:02:58,660 250 | It would look something like this. 251 | 252 | 53 253 | 00:02:58,660 --> 00:03:01,450 254 | Here I have the same 255 | three pixels as before. 256 | 257 | 54 258 | 00:03:01,450 --> 00:03:03,940 259 | Now we know that we 260 | need to scale by 1.5. 261 | 262 | 55 263 | 00:03:03,940 --> 00:03:08,540 264 | So we know that the outfile row is 265 | going to have four pixels in it. 266 | 267 | 56 268 | 00:03:08,540 --> 00:03:11,920 269 | So for each one of those 270 | four pixels in the outfile, 271 | 272 | 57 273 | 00:03:11,920 --> 00:03:15,670 274 | I figure out what the 275 | corresponding pixel is. 276 | 277 | 58 278 | 00:03:15,670 --> 00:03:20,150 279 | So see if you can figure out 280 | what pattern I'm using here. 281 | 282 | 59 283 | 00:03:20,150 --> 00:03:24,120 284 | I'll use the same pattern 285 | for a float input of 0.5. 286 | 287 | 60 288 | 00:03:24,120 --> 00:03:26,830 289 | With three pixels in 290 | the original row, I'll 291 | 292 | 61 293 | 00:03:26,830 --> 00:03:29,970 294 | calculate that I'll need two 295 | pixels in my outfile row. 296 | 297 | 62 298 | 00:03:29,970 --> 00:03:34,230 299 | So I'll calculate the 300 | corresponding pixel as follows. 301 | 302 | 63 303 | 00:03:34,230 --> 00:03:36,920 304 | All right, so now that we've 305 | figured out that pattern, 306 | 307 | 64 308 | 00:03:36,920 --> 00:03:39,990 309 | let's talk about the two 310 | functions that we'll need to use. 311 | 312 | 65 313 | 00:03:39,990 --> 00:03:42,750 314 | To read into the file, we'll 315 | use the fread function. 316 | 317 | 66 318 | 00:03:42,750 --> 00:03:45,880 319 | And then to write the 320 | files, we'll use fwrite. 321 | 322 | 67 323 | 00:03:45,880 --> 00:03:49,270 324 | So the next thing that we 325 | need to talk about is padding. 326 | 327 | 68 328 | 00:03:49,270 --> 00:03:52,270 329 | In a bitmap, every pixel 330 | is three bytes long. 331 | 332 | 69 333 | 00:03:52,270 --> 00:03:56,700 334 | Now, a requirement for the bitmap image 335 | is that the length of each scanline 336 | 337 | 70 338 | 00:03:56,700 --> 00:03:58,800 339 | must be a multiple of four bytes. 340 | 341 | 71 342 | 00:03:58,800 --> 00:04:01,620 343 | So if the number of pixels 344 | is not a multiple of four, 345 | 346 | 72 347 | 00:04:01,620 --> 00:04:05,290 348 | then we'll need to add padding 349 | where padding is just a single zero 350 | 351 | 73 352 | 00:04:05,290 --> 00:04:06,860 353 | character. 354 | 355 | 74 356 | 00:04:06,860 --> 00:04:09,960 357 | In this example, I have 358 | 4 pixels in my row. 359 | 360 | 75 361 | 00:04:09,960 --> 00:04:14,010 362 | Now, with 4 pixels 3 bytes 363 | each, that equates to 12 bytes. 364 | 365 | 76 366 | 00:04:14,010 --> 00:04:16,160 367 | So I won't need to add any padding. 368 | 369 | 77 370 | 00:04:16,160 --> 00:04:22,089 371 | But instead, if I had 5 triples, then 372 | 5 times 3 is 15, not a multiple of 4. 373 | 374 | 78 375 | 00:04:22,089 --> 00:04:25,970 376 | So I'd need to add one 377 | single padding character. 378 | 379 | 79 380 | 00:04:25,970 --> 00:04:29,960 381 | Then if I had six RGBtriples, 382 | I'd add 2 characters of padding. 383 | 384 | 80 385 | 00:04:29,960 --> 00:04:34,340 386 | Finally, with 3 RGBtriples, 387 | I'd add 3 units of padding. 388 | 389 | 81 390 | 00:04:34,340 --> 00:04:36,400 391 | I've included the 392 | equation for padding here. 393 | 394 | 82 395 | 00:04:36,400 --> 00:04:39,550 396 | And it can also be found in 397 | the problem specification. 398 | 399 | 83 400 | 00:04:39,550 --> 00:04:42,320 401 | Notice how padding depends 402 | on width of the bitmap 403 | 404 | 84 405 | 00:04:42,320 --> 00:04:44,480 406 | and the size of an RGBtriple. 407 | 408 | 85 409 | 00:04:44,480 --> 00:04:47,270 410 | Now the size of the RGBtriple 411 | is going to be constant. 412 | 413 | 86 414 | 00:04:47,270 --> 00:04:50,950 415 | So the only thing that might be 416 | changing is the width of the bitmap. 417 | 418 | 87 419 | 00:04:50,950 --> 00:04:54,120 420 | So if the outfile and infile 421 | have different widths, 422 | 423 | 88 424 | 00:04:54,120 --> 00:04:57,330 425 | then they may have a 426 | different amount of padding. 427 | 428 | 89 429 | 00:04:57,330 --> 00:04:59,700 430 | Remember our discussion 431 | about bitmap headers 432 | 433 | 90 434 | 00:04:59,700 --> 00:05:03,080 435 | where we calculated how the 436 | old header information might 437 | 438 | 91 439 | 00:05:03,080 --> 00:05:04,650 440 | change for the outfile. 441 | 442 | 92 443 | 00:05:04,650 --> 00:05:07,870 444 | Well, because the padding is going 445 | to be different for the infile 446 | 447 | 93 448 | 00:05:07,870 --> 00:05:12,840 449 | and the outfile, then we may also 450 | need to keep track of that as well. 451 | 452 | 94 453 | 00:05:12,840 --> 00:05:16,020 454 | Now, why do we keep track of 455 | both the old and the new padding? 456 | 457 | 95 458 | 00:05:16,020 --> 00:05:18,020 459 | Well, we'll need the old 460 | padding because we'll 461 | 462 | 96 463 | 00:05:18,020 --> 00:05:22,010 464 | want to skip over the padding 465 | in the infile using fseek. 466 | 467 | 97 468 | 00:05:22,010 --> 00:05:25,470 469 | And then we need to know how much 470 | padding to add into the outfile. 471 | 472 | 98 473 | 00:05:25,470 --> 00:05:29,720 474 | And we'll use fputc to 475 | put those characters in. 476 | 477 | 99 478 | 00:05:29,720 --> 00:05:31,760 479 | Now that we have a 480 | firm grasp on padding, 481 | 482 | 100 483 | 00:05:31,760 --> 00:05:34,360 484 | we can resize our entire image. 485 | 486 | 101 487 | 00:05:34,360 --> 00:05:38,780 488 | So once we figure out which row should 489 | be written, then let's seek to that, 490 | 491 | 102 492 | 00:05:38,780 --> 00:05:43,460 493 | draw the pixels into the outfile 494 | and write the outfile's padding. 495 | 496 | 103 497 | 00:05:43,460 --> 00:05:46,180 498 | With that, we've resized our image. 499 | 500 | 104 501 | 00:05:46,180 --> 00:05:47,590 502 | My name is Zamyla. 503 | 504 | 105 505 | 00:05:47,590 --> 00:05:50,370 506 | And this was resize. 507 | 508 | 106 509 | 00:05:50,370 --> 00:05:52,129 -------------------------------------------------------------------------------- /2016/en/walkthroughs/search.srt: -------------------------------------------------------------------------------- 1 | 1 2 | 00:00:00,000 --> 00:00:00,499 3 | 4 | 5 | 2 6 | 00:00:00,499 --> 00:00:04,290 7 | ZAMYLA CHAN: Let's find 8 | the needle in the haystack. 9 | 10 | 3 11 | 00:00:04,290 --> 00:00:07,920 12 | Today in find.c we're going to 13 | help implement a program that 14 | 15 | 4 16 | 00:00:07,920 --> 00:00:10,590 17 | prompts the user for 18 | numbers to fill the haystack 19 | 20 | 5 21 | 00:00:10,590 --> 00:00:13,270 22 | and then searches the 23 | haystack for a needle. 24 | 25 | 6 26 | 00:00:13,270 --> 00:00:17,300 27 | Now, find.c calls sort and 28 | search, which are both functions 29 | 30 | 7 31 | 00:00:17,300 --> 00:00:19,010 32 | to find in helpers.c. 33 | 34 | 8 35 | 00:00:19,010 --> 00:00:20,880 36 | It's actually helpers.c 37 | where we're going 38 | 39 | 9 40 | 00:00:20,880 --> 00:00:23,980 41 | to be doing our programming today. 42 | 43 | 10 44 | 00:00:23,980 --> 00:00:25,690 45 | So what do we have to do? 46 | 47 | 11 48 | 00:00:25,690 --> 00:00:27,700 49 | Well, first we need to 50 | implement search, which 51 | 52 | 12 53 | 00:00:27,700 --> 00:00:31,670 54 | is a function that returns true if 55 | the value is found in the haystack 56 | 57 | 13 58 | 00:00:31,670 --> 00:00:33,530 59 | and false otherwise. 60 | 61 | 14 62 | 00:00:33,530 --> 00:00:37,820 63 | And then we also have to do sort, 64 | which sorts the values in the array 65 | 66 | 15 67 | 00:00:37,820 --> 00:00:39,510 68 | in incrementing order. 69 | 70 | 16 71 | 00:00:39,510 --> 00:00:41,500 72 | So first let's talk about search. 73 | 74 | 17 75 | 00:00:41,500 --> 00:00:44,220 76 | If you look at the 77 | distribution code in helpers.c 78 | 79 | 18 80 | 00:00:44,220 --> 00:00:47,750 81 | you'll find a preexisting 82 | linear search implementation 83 | 84 | 19 85 | 00:00:47,750 --> 00:00:50,700 86 | but we know that we can 87 | do much better than this. 88 | 89 | 20 90 | 00:00:50,700 --> 00:00:55,500 91 | Linear search is in O(n) time, 92 | which means that it's quite slow. 93 | 94 | 21 95 | 00:00:55,500 --> 00:01:00,320 96 | Instead of slowly iterating over 97 | every element of the list up until n, 98 | 99 | 22 100 | 00:01:00,320 --> 00:01:02,630 101 | let's talk about binary search. 102 | 103 | 23 104 | 00:01:02,630 --> 00:01:06,560 105 | Now, linear search can search any 106 | list, whereas binary search requires 107 | 108 | 24 109 | 00:01:06,560 --> 00:01:08,850 110 | that the list is sorted already. 111 | 112 | 25 113 | 00:01:08,850 --> 00:01:13,600 114 | But as long as you have a sorted list 115 | then binary search operates in O(log n) 116 | 117 | 26 118 | 00:01:13,600 --> 00:01:15,900 119 | time, which is quite efficient. 120 | 121 | 27 122 | 00:01:15,900 --> 00:01:17,850 123 | Let's take a look at an example. 124 | 125 | 28 126 | 00:01:17,850 --> 00:01:22,270 127 | Here I've populated an integer array 128 | of size nine with nine integers 129 | 130 | 29 131 | 00:01:22,270 --> 00:01:25,000 132 | and let's say we're 133 | looking for the number 17. 134 | 135 | 30 136 | 00:01:25,000 --> 00:01:27,720 137 | Now in this example, if we 138 | were to do a linear search 139 | 140 | 31 141 | 00:01:27,720 --> 00:01:32,570 142 | then it would take us 7 checks starting 143 | from index 0 all the way till index 7 144 | 145 | 32 146 | 00:01:32,570 --> 00:01:34,120 147 | to find that number. 148 | 149 | 33 150 | 00:01:34,120 --> 00:01:36,940 151 | So let's see how we can implement 152 | this using binary search 153 | 154 | 34 155 | 00:01:36,940 --> 00:01:39,380 156 | and find that needle a lot faster. 157 | 158 | 35 159 | 00:01:39,380 --> 00:01:42,780 160 | In binary search we start by 161 | looking at the whole array. 162 | 163 | 36 164 | 00:01:42,780 --> 00:01:46,910 165 | So from the left side of the array to 166 | the right side, we look at the entirety 167 | 168 | 37 169 | 00:01:46,910 --> 00:01:48,390 170 | and find the middle. 171 | 172 | 38 173 | 00:01:48,390 --> 00:01:50,560 174 | In this case, the 175 | middle is that index 4. 176 | 177 | 39 178 | 00:01:50,560 --> 00:01:52,310 179 | The value is 10. 180 | 181 | 40 182 | 00:01:52,310 --> 00:01:55,470 183 | So the assumption under binary 184 | search of the list is sorted. 185 | 186 | 41 187 | 00:01:55,470 --> 00:01:59,000 188 | So while 10 is not 17 and 189 | because the list is sorted, 190 | 191 | 42 192 | 00:01:59,000 --> 00:02:03,310 193 | we know that we don't need to look at 194 | the left half of the array anymore. 195 | 196 | 43 197 | 00:02:03,310 --> 00:02:05,360 198 | So similar to the way 199 | that we just throw aside 200 | 201 | 44 202 | 00:02:05,360 --> 00:02:08,850 203 | one half of the phone book in 204 | the beginning of this course, 205 | 206 | 45 207 | 00:02:08,850 --> 00:02:13,500 208 | we can just move our left 209 | bound all the way to the middle 210 | 211 | 46 212 | 00:02:13,500 --> 00:02:17,470 213 | but we've already checked the middle so 214 | we can get a little bit more efficient 215 | 216 | 47 217 | 00:02:17,470 --> 00:02:19,660 218 | and say, well since we've 219 | already checked the middle 220 | 221 | 48 222 | 00:02:19,660 --> 00:02:22,300 223 | we know that's not part of the 224 | array that we're looking for 225 | 226 | 49 227 | 00:02:22,300 --> 00:02:26,380 228 | so let's push they're bound to 229 | just beyond where the middle was. 230 | 231 | 50 232 | 00:02:26,380 --> 00:02:31,420 233 | So now we have our left bound at index 234 | 5 and our right bound stays the same. 235 | 236 | 51 237 | 00:02:31,420 --> 00:02:35,020 238 | Let's calculate the middle and 239 | we find, truncating the integer, 240 | 241 | 52 242 | 00:02:35,020 --> 00:02:37,460 243 | that the middle is at index 6. 244 | 245 | 53 246 | 00:02:37,460 --> 00:02:39,850 247 | So we check that value there, 16. 248 | 249 | 54 250 | 00:02:39,850 --> 00:02:43,640 251 | 16 is not 17, in fact 252 | it's less than 17, which 253 | 254 | 55 255 | 00:02:43,640 --> 00:02:48,410 256 | means that we can discard the left half 257 | again and just look at the right side. 258 | 259 | 56 260 | 00:02:48,410 --> 00:02:53,970 261 | So then we move our left bound all the 262 | way to index 7 and the right bounds 263 | 264 | 57 265 | 00:02:53,970 --> 00:02:55,400 266 | stays at 8. 267 | 268 | 58 269 | 00:02:55,400 --> 00:02:58,750 270 | Calculating the middle between 271 | 7 and 8 brings us to 7. 272 | 273 | 59 274 | 00:02:58,750 --> 00:03:03,460 275 | We check that value and 276 | indeed we found our needle. 277 | 278 | 60 279 | 00:03:03,460 --> 00:03:06,990 280 | So let's talk about some 281 | pseudocode for this. 282 | 283 | 61 284 | 00:03:06,990 --> 00:03:09,060 285 | Essentially, while 286 | the length of the list 287 | 288 | 62 289 | 00:03:09,060 --> 00:03:12,240 290 | is greater than zero, that is 291 | we still have things to look at, 292 | 293 | 63 294 | 00:03:12,240 --> 00:03:14,550 295 | we want to look at 296 | the middle of the list 297 | 298 | 64 299 | 00:03:14,550 --> 00:03:18,550 300 | and if that middle is our needle if 301 | the number is found then that's great 302 | 303 | 65 304 | 00:03:18,550 --> 00:03:20,260 305 | and we can return true. 306 | 307 | 66 308 | 00:03:20,260 --> 00:03:23,660 309 | Otherwise we want to either 310 | search left or search right 311 | 312 | 67 313 | 00:03:23,660 --> 00:03:27,230 314 | depending on whether the number is 315 | higher or lower than our needle. 316 | 317 | 68 318 | 00:03:27,230 --> 00:03:30,780 319 | And then finally, if 320 | we've executed all of that 321 | 322 | 69 323 | 00:03:30,780 --> 00:03:33,050 324 | and we don't have any 325 | more list remaining then 326 | 327 | 70 328 | 00:03:33,050 --> 00:03:35,360 329 | that means that we 330 | return false because that 331 | 332 | 71 333 | 00:03:35,360 --> 00:03:39,770 334 | means that the needle is definitely 335 | not in that particular haystack. 336 | 337 | 72 338 | 00:03:39,770 --> 00:03:40,780 339 | Congratulations. 340 | 341 | 73 342 | 00:03:40,780 --> 00:03:45,780 343 | You've implemented a fast search, 344 | and now we can move on to sort. 345 | 346 | 74 347 | 00:03:45,780 --> 00:03:47,090 -------------------------------------------------------------------------------- /2016/en/walkthroughs/size.srt: -------------------------------------------------------------------------------- 1 | 1 2 | 00:00:00,000 --> 00:00:00,515 3 | 4 | 5 | 2 6 | 00:00:00,515 --> 00:00:03,840 7 | ZAMYLA CHAN: So how many words 8 | can your spell-check check? 9 | 10 | 3 11 | 00:00:03,840 --> 00:00:06,800 12 | Well, if you've 13 | implemented load correctly, 14 | 15 | 4 16 | 00:00:06,800 --> 00:00:09,330 17 | then size should be a 18 | piece of cake, simply 19 | 20 | 5 21 | 00:00:09,330 --> 00:00:14,490 22 | returning a single variable of how 23 | many words are in your dictionary. 24 | 25 | 6 26 | 00:00:14,490 --> 00:00:16,184 -------------------------------------------------------------------------------- /2016/en/walkthroughs/sort_less.srt: -------------------------------------------------------------------------------- 1 | 1 2 | 00:00:00,000 --> 00:00:00,220 3 | 4 | 5 | 2 6 | 00:00:00,220 --> 00:00:01,428 7 | ZAMYLA CHAN: Congratulations. 8 | 9 | 3 10 | 00:00:01,428 --> 00:00:03,750 11 | You've implemented a fast binary search. 12 | 13 | 4 14 | 00:00:03,750 --> 00:00:06,100 15 | And now we can move on to sort. 16 | 17 | 5 18 | 00:00:06,100 --> 00:00:08,250 19 | In the sort, you have the 20 | option of implementing 21 | 22 | 6 23 | 00:00:08,250 --> 00:00:10,350 24 | a selection sort or a bubble sort. 25 | 26 | 7 27 | 00:00:10,350 --> 00:00:12,860 28 | So let's look at selection sort first. 29 | 30 | 8 31 | 00:00:12,860 --> 00:00:16,400 32 | In selection sort, we start by 33 | going to the beginning of the array, 34 | 35 | 9 36 | 00:00:16,400 --> 00:00:19,580 37 | and then following through to 38 | replace the beginning of the array 39 | 40 | 10 41 | 00:00:19,580 --> 00:00:21,540 42 | with the minimum value found. 43 | 44 | 11 45 | 00:00:21,540 --> 00:00:22,670 46 | How does that work? 47 | 48 | 12 49 | 00:00:22,670 --> 00:00:24,420 50 | Let's go through this example. 51 | 52 | 13 53 | 00:00:24,420 --> 00:00:27,700 54 | In this example, I have a 55 | short list of five integers. 56 | 57 | 14 58 | 00:00:27,700 --> 00:00:30,770 59 | We're going to start by replacing 60 | index 0 with the minimum value 61 | 62 | 15 63 | 00:00:30,770 --> 00:00:32,670 64 | that we find in this array. 65 | 66 | 16 67 | 00:00:32,670 --> 00:00:36,430 68 | So knowing that I start at 0, I'm 69 | going to put my i index there. 70 | 71 | 17 72 | 00:00:36,430 --> 00:00:38,900 73 | Then I'm going to look 74 | at the rest of the list. 75 | 76 | 18 77 | 00:00:38,900 --> 00:00:41,820 78 | So starting at index 79 | 1, I have the value 5. 80 | 81 | 19 82 | 00:00:41,820 --> 00:00:44,450 83 | Now, I haven't looked at any 84 | other values in this array. 85 | 86 | 20 87 | 00:00:44,450 --> 00:00:48,540 88 | So for right now, let's say that 89 | this value 5 is the minimum. 90 | 91 | 21 92 | 00:00:48,540 --> 00:00:52,770 93 | Then we progress to index 2, where 94 | the value 2 there is less than 5. 95 | 96 | 22 97 | 00:00:52,770 --> 00:00:55,800 98 | So that becomes where 99 | the new minimum is. 100 | 101 | 23 102 | 00:00:55,800 --> 00:00:59,540 103 | Progressing to index 3, we 104 | find that 1 is less than 2. 105 | 106 | 24 107 | 00:00:59,540 --> 00:01:02,790 108 | So then that becomes the 109 | location of the new minimum. 110 | 111 | 25 112 | 00:01:02,790 --> 00:01:05,990 113 | Going to index 4, we find that, 114 | well, 4 is greater than 1. 115 | 116 | 26 117 | 00:01:05,990 --> 00:01:09,160 118 | So when we were at index 3, 119 | we actually found the minimum. 120 | 121 | 27 122 | 00:01:09,160 --> 00:01:12,600 123 | So then now that we found that, 124 | we switch those two values 125 | 126 | 28 127 | 00:01:12,600 --> 00:01:14,930 128 | from the beginning to 129 | where we found the minimum. 130 | 131 | 29 132 | 00:01:14,930 --> 00:01:17,540 133 | So now we have an 134 | array that's definitely 135 | 136 | 30 137 | 00:01:17,540 --> 00:01:21,500 138 | sorted for the very first value, 139 | but not for the remaining four. 140 | 141 | 31 142 | 00:01:21,500 --> 00:01:25,670 143 | So then we advance our i indicator 144 | for the remaining four in the list. 145 | 146 | 32 147 | 00:01:25,670 --> 00:01:27,990 148 | We don't need to worry 149 | about that first value 150 | 151 | 33 152 | 00:01:27,990 --> 00:01:30,480 153 | because we know that 154 | it's the minimum value. 155 | 156 | 34 157 | 00:01:30,480 --> 00:01:32,760 158 | So then we do the same 159 | process as before, 160 | 161 | 35 162 | 00:01:32,760 --> 00:01:35,230 163 | where we search the 164 | remaining three elements 165 | 166 | 36 167 | 00:01:35,230 --> 00:01:37,640 168 | in that list for the minimum value. 169 | 170 | 37 171 | 00:01:37,640 --> 00:01:41,860 172 | In this case, we find that it's actually 173 | the first one we checked, at index 2. 174 | 175 | 38 176 | 00:01:41,860 --> 00:01:44,950 177 | So then what we do is we 178 | switch the 2 with the 5. 179 | 180 | 39 181 | 00:01:44,950 --> 00:01:47,810 182 | So now the first two elements 183 | of the list are sorted. 184 | 185 | 40 186 | 00:01:47,810 --> 00:01:50,440 187 | And now we look at the remaining three. 188 | 189 | 41 190 | 00:01:50,440 --> 00:01:54,200 191 | For the remaining three, we find 192 | that the minimum is, well, 3. 193 | 194 | 42 195 | 00:01:54,200 --> 00:01:57,980 196 | And so we switch that with the 197 | 5, and continue that process 198 | 199 | 43 200 | 00:01:57,980 --> 00:02:01,019 201 | until we have a completely sorted list. 202 | 203 | 44 204 | 00:02:01,019 --> 00:02:04,310 205 | Now that we've gone through an example, 206 | let's look at what the pseudocode looks 207 | 208 | 45 209 | 00:02:04,310 --> 00:02:05,550 210 | like. 211 | 212 | 46 213 | 00:02:05,550 --> 00:02:10,229 214 | So for i equals 0 to n minus 2-- 215 | that is, from the very first element 216 | 217 | 47 218 | 00:02:10,229 --> 00:02:14,050 219 | all the way to the penultimate one-- 220 | that is, not the last one, but the one 221 | 222 | 48 223 | 00:02:14,050 --> 00:02:18,630 224 | right before that-- we want to find 225 | the smallest element from i plus 1 226 | 227 | 49 228 | 00:02:18,630 --> 00:02:22,350 229 | to n minus 1-- so from the 230 | second element of the array 231 | 232 | 50 233 | 00:02:22,350 --> 00:02:23,750 234 | all the way to the end. 235 | 236 | 51 237 | 00:02:23,750 --> 00:02:26,920 238 | From there, I exchange the 239 | smallest element with the element 240 | 241 | 52 242 | 00:02:26,920 --> 00:02:28,690 243 | that I had at i. 244 | 245 | 53 246 | 00:02:28,690 --> 00:02:32,280 247 | Now, by incrementing i 248 | every time, essentially what 249 | 250 | 54 251 | 00:02:32,280 --> 00:02:36,310 252 | we do is we make sure that in order from 253 | the beginning all the way to the end, 254 | 255 | 55 256 | 00:02:36,310 --> 00:02:39,320 257 | we find the minimum value of the array. 258 | 259 | 56 260 | 00:02:39,320 --> 00:02:43,920 261 | And that way, we have an array 262 | sorted in incremental order. 263 | 264 | 57 265 | 00:02:43,920 --> 00:02:47,630 266 | We've finished talking about selection 267 | sort, so let's talk about bubble sort. 268 | 269 | 58 270 | 00:02:47,630 --> 00:02:51,810 271 | In bubble sort, we iterate over a 272 | list, comparing adjacent elements. 273 | 274 | 59 275 | 00:02:51,810 --> 00:02:55,380 276 | Now, if those elements are in the 277 | wrong order, then we swap them. 278 | 279 | 60 280 | 00:02:55,380 --> 00:02:58,780 281 | This way, the largest element 282 | will sort of bubble to the end. 283 | 284 | 61 285 | 00:02:58,780 --> 00:03:00,320 286 | That's how it gets its name. 287 | 288 | 62 289 | 00:03:00,320 --> 00:03:02,360 290 | And then we repeat 291 | that for the whole list 292 | 293 | 63 294 | 00:03:02,360 --> 00:03:05,030 295 | until no elements have been swapped. 296 | 297 | 64 298 | 00:03:05,030 --> 00:03:08,000 299 | Then we consider the list 300 | as successfully sorted. 301 | 302 | 65 303 | 00:03:08,000 --> 00:03:10,300 304 | Let's take a look at an example. 305 | 306 | 66 307 | 00:03:10,300 --> 00:03:12,120 308 | Here in my five-element 309 | array, we're going 310 | 311 | 67 312 | 00:03:12,120 --> 00:03:15,380 313 | to start at the beginning 314 | at index 0 and index 1. 315 | 316 | 68 317 | 00:03:15,380 --> 00:03:19,130 318 | Comparing these, I see that the 319 | 3 and 5 are, in fact, in order. 320 | 321 | 69 322 | 00:03:19,130 --> 00:03:21,260 323 | 3 is less than 5. 324 | 325 | 70 326 | 00:03:21,260 --> 00:03:25,080 327 | So then I proceed to 328 | compare index 1 and 2. 329 | 330 | 71 331 | 00:03:25,080 --> 00:03:26,430 332 | Now, 5 and 2 are out of order. 333 | 334 | 72 335 | 00:03:26,430 --> 00:03:27,840 336 | So I'm going to swap those. 337 | 338 | 73 339 | 00:03:27,840 --> 00:03:29,770 340 | And then I compare 2 and 3. 341 | 342 | 74 343 | 00:03:29,770 --> 00:03:32,620 344 | 5 is greater than 1, 345 | so I swap those again. 346 | 347 | 75 348 | 00:03:32,620 --> 00:03:35,650 349 | And then continuing on, I swap 5 and 4. 350 | 351 | 76 352 | 00:03:35,650 --> 00:03:40,640 353 | So you see how 5 started out at the 354 | second element, and now is at the end, 355 | 356 | 77 357 | 00:03:40,640 --> 00:03:43,190 358 | being the largest element in the list. 359 | 360 | 78 361 | 00:03:43,190 --> 00:03:46,910 362 | Now that 5's bubbled through, I go 363 | back to the beginning of my list. 364 | 365 | 79 366 | 00:03:46,910 --> 00:03:50,690 367 | I look at indices 0 and 1, and 368 | find that 3 is out of order 369 | 370 | 80 371 | 00:03:50,690 --> 00:03:52,580 372 | because it's greater than 2. 373 | 374 | 81 375 | 00:03:52,580 --> 00:03:55,230 376 | So I swap those, and then continue on. 377 | 378 | 82 379 | 00:03:55,230 --> 00:03:59,310 380 | 3 then bubbles through 381 | to element 2, but find 382 | 383 | 83 384 | 00:03:59,310 --> 00:04:03,840 385 | that when we advance to comparing 3 386 | and 4, those are actually in order. 387 | 388 | 84 389 | 00:04:03,840 --> 00:04:07,490 390 | So the 3 bubbled its way, but 391 | not all the way to the end. 392 | 393 | 85 394 | 00:04:07,490 --> 00:04:10,170 395 | Now that 5's bubbled its 396 | way to the end of the list, 397 | 398 | 86 399 | 00:04:10,170 --> 00:04:12,220 400 | we go back to the beginning again. 401 | 402 | 87 403 | 00:04:12,220 --> 00:04:16,700 404 | So we compare indices 0 and 1, 405 | and find that 3 is larger than 2. 406 | 407 | 88 408 | 00:04:16,700 --> 00:04:17,649 409 | It's out of order. 410 | 411 | 89 412 | 00:04:17,649 --> 00:04:19,029 413 | So we swap those. 414 | 415 | 90 416 | 00:04:19,029 --> 00:04:21,709 417 | Then proceeding on, we compare 3 and 1. 418 | 419 | 91 420 | 00:04:21,709 --> 00:04:24,610 421 | And 3 is larger than 1, 422 | so we swap that again. 423 | 424 | 92 425 | 00:04:24,610 --> 00:04:28,030 426 | So so far, 3's bubbled its way 427 | from the beginning all the way 428 | 429 | 93 430 | 00:04:28,030 --> 00:04:29,500 431 | to the middle of the list. 432 | 433 | 94 434 | 00:04:29,500 --> 00:04:34,170 435 | But 3 isn't greater than 4, so 436 | we actually don't swap those. 437 | 438 | 95 439 | 00:04:34,170 --> 00:04:37,720 440 | We don't need to make one last 441 | comparison because 5 already 442 | 443 | 96 444 | 00:04:37,720 --> 00:04:40,780 445 | bubbled its way to the end of 446 | the list in the first iteration. 447 | 448 | 97 449 | 00:04:40,780 --> 00:04:42,890 450 | So we can just go to 451 | the beginning again. 452 | 453 | 98 454 | 00:04:42,890 --> 00:04:45,310 455 | We look at index 0 and index 1. 456 | 457 | 99 458 | 00:04:45,310 --> 00:04:47,650 459 | And we swap 2 and 1, and then proceed. 460 | 461 | 100 462 | 00:04:47,650 --> 00:04:49,610 463 | And we don't need to swap 2 and 3. 464 | 465 | 101 466 | 00:04:49,610 --> 00:04:51,790 467 | So then 3 is set. 468 | 469 | 102 470 | 00:04:51,790 --> 00:04:55,490 471 | Then comparing 1 and 2, 472 | no swaps need to be made. 473 | 474 | 103 475 | 00:04:55,490 --> 00:04:59,300 476 | So then that means that we 477 | finished sorting our list. 478 | 479 | 104 480 | 00:04:59,300 --> 00:05:00,590 481 | That was bubble sort. 482 | 483 | 105 484 | 00:05:00,590 --> 00:05:02,660 485 | And we already talked 486 | about selection sort. 487 | 488 | 106 489 | 00:05:02,660 --> 00:05:03,940 490 | So there you have it. 491 | 492 | 107 493 | 00:05:03,940 --> 00:05:08,010 494 | Now you can sort an array 495 | and do a binary search on it. 496 | 497 | 108 498 | 00:05:08,010 --> 00:05:12,270 499 | My name is Zamyla, and this was find. 500 | 501 | 109 502 | 00:05:12,270 --> 00:05:13,886 -------------------------------------------------------------------------------- /2016/en/walkthroughs/sort_more.srt: -------------------------------------------------------------------------------- 1 | 1 2 | 00:00:00,000 --> 00:00:00,499 3 | 4 | 5 | 2 6 | 00:00:00,499 --> 00:00:05,210 7 | ZAMYLA CHAN: Our challenge for sort 8 | is to implement a sort in O of n time. 9 | 10 | 3 11 | 00:00:05,210 --> 00:00:06,600 12 | How might we do this? 13 | 14 | 4 15 | 00:00:06,600 --> 00:00:08,880 16 | Well, counting sort is one such example. 17 | 18 | 5 19 | 00:00:08,880 --> 00:00:12,530 20 | Counting sort will use key 21 | values as indices for an array 22 | 23 | 6 24 | 00:00:12,530 --> 00:00:16,700 25 | and then uses that array to determine 26 | the positions for the final array. 27 | 28 | 7 29 | 00:00:16,700 --> 00:00:18,970 30 | Now, counting sort does 31 | depend on the assumption 32 | 33 | 8 34 | 00:00:18,970 --> 00:00:21,890 35 | that we have a known and 36 | finite range of numbers 37 | 38 | 9 39 | 00:00:21,890 --> 00:00:25,280 40 | and that that range 41 | isn't terribly large. 42 | 43 | 10 44 | 00:00:25,280 --> 00:00:28,150 45 | So counting sort ultimately 46 | takes place in big O of n 47 | 48 | 11 49 | 00:00:28,150 --> 00:00:31,300 50 | plus k time, which resolves to O of n. 51 | 52 | 12 53 | 00:00:31,300 --> 00:00:32,759 54 | Let's look at an example. 55 | 56 | 13 57 | 00:00:32,759 --> 00:00:34,610 58 | Here I have an array of five integers. 59 | 60 | 14 61 | 00:00:34,610 --> 00:00:38,070 62 | And I know that my random integer 63 | generator only generates numbers 64 | 65 | 15 66 | 00:00:38,070 --> 00:00:40,800 67 | from 0 all the way to 6, inclusive. 68 | 69 | 16 70 | 00:00:40,800 --> 00:00:43,500 71 | So I generate a counting 72 | array, which will 73 | 74 | 17 75 | 00:00:43,500 --> 00:00:47,230 76 | count the number of entries for every 77 | single integer within this range. 78 | 79 | 18 80 | 00:00:47,230 --> 00:00:50,180 81 | So I start at the very 82 | first element of this array. 83 | 84 | 19 85 | 00:00:50,180 --> 00:00:51,890 86 | And I have the number 3. 87 | 88 | 20 89 | 00:00:51,890 --> 00:00:56,000 90 | So then I go to index 3 of my 91 | counting array, and then I put a 1 92 | 93 | 21 94 | 00:00:56,000 --> 00:00:57,620 95 | there at that element. 96 | 97 | 22 98 | 00:00:57,620 --> 00:01:02,520 99 | I then go to the next element in 100 | my array, 6, so I go to index 6 101 | 102 | 23 103 | 00:01:02,520 --> 00:01:04,450 104 | and I put a 1 there. 105 | 106 | 24 107 | 00:01:04,450 --> 00:01:07,490 108 | Progressing to the third element 109 | of the array, I have the number 1. 110 | 111 | 25 112 | 00:01:07,490 --> 00:01:12,110 113 | So following this pattern, I go to index 114 | number 1 and I increment the count. 115 | 116 | 26 117 | 00:01:12,110 --> 00:01:16,380 118 | So then, when I get to the fourth 119 | element and I have the number 1, 120 | 121 | 27 122 | 00:01:16,380 --> 00:01:19,100 123 | I go to index 1 and I 124 | simply increment the count, 125 | 126 | 28 127 | 00:01:19,100 --> 00:01:23,340 128 | indicating that so far I've 129 | found two ones in my array. 130 | 131 | 29 132 | 00:01:23,340 --> 00:01:26,600 133 | So finally, after we 134 | increment the count at 3, 135 | 136 | 30 137 | 00:01:26,600 --> 00:01:29,740 138 | we have enough information 139 | in this counting array 140 | 141 | 31 142 | 00:01:29,740 --> 00:01:34,270 143 | to be able to fill in our original 144 | array in incrementing order. 145 | 146 | 32 147 | 00:01:34,270 --> 00:01:36,900 148 | But I'll leave that to 149 | you to figure that out. 150 | 151 | 33 152 | 00:01:36,900 --> 00:01:41,170 153 | My name is Zamyla, and this was fun. 154 | 155 | 34 156 | 00:01:41,170 --> 00:01:42,561 -------------------------------------------------------------------------------- /2016/en/walkthroughs/speller.srt: -------------------------------------------------------------------------------- 1 | 1 2 | 00:00:00,000 --> 00:00:00,610 3 | 4 | 5 | 2 6 | 00:00:00,610 --> 00:00:02,750 7 | How many words can a 8 | spell checker check? 9 | 10 | 3 11 | 00:00:02,750 --> 00:00:05,160 12 | Well, let's find out with Speller. 13 | 14 | 4 15 | 00:00:05,160 --> 00:00:07,830 16 | Let's dive right into 17 | the distribution code. 18 | 19 | 5 20 | 00:00:07,830 --> 00:00:11,010 21 | Speller.c will call load 22 | on a dictionary file 23 | 24 | 6 25 | 00:00:11,010 --> 00:00:13,590 26 | and put it by the user, 27 | where the dictionary contains 28 | 29 | 7 30 | 00:00:13,590 --> 00:00:15,740 31 | valid words, one per line. 32 | 33 | 8 34 | 00:00:15,740 --> 00:00:18,870 35 | Then, it calls check on 36 | each word in a text file 37 | 38 | 9 39 | 00:00:18,870 --> 00:00:22,100 40 | that the user provided and prints 41 | all of the misspelled words found 42 | 43 | 10 44 | 00:00:22,100 --> 00:00:23,190 45 | in that file. 46 | 47 | 11 48 | 00:00:23,190 --> 00:00:27,650 49 | Then, it calls size to determine the 50 | number of words in the dictionary. 51 | 52 | 12 53 | 00:00:27,650 --> 00:00:31,300 54 | And finally, calls unload to 55 | free up all of the memory used 56 | 57 | 13 58 | 00:00:31,300 --> 00:00:33,930 59 | while doing this process. 60 | 61 | 14 62 | 00:00:33,930 --> 00:00:37,690 63 | Our job is to implement the 64 | four functions in dictionary.c. 65 | 66 | 15 67 | 00:00:37,690 --> 00:00:42,130 68 | Load, which loads the dictionary into 69 | a data structure that we've created. 70 | 71 | 16 72 | 00:00:42,130 --> 00:00:45,100 73 | Check, which then checks 74 | that data structure to see 75 | 76 | 17 77 | 00:00:45,100 --> 00:00:47,640 78 | if a given word is in the dictionary. 79 | 80 | 18 81 | 00:00:47,640 --> 00:00:50,800 82 | Size, which returns the number 83 | of words in the dictionary. 84 | 85 | 19 86 | 00:00:50,800 --> 00:00:55,200 87 | And finally, unload, which frees 88 | the dictionary from memory. 89 | 90 | 20 91 | 00:00:55,200 --> 00:00:56,539 -------------------------------------------------------------------------------- /2016/en/walkthroughs/unload.srt: -------------------------------------------------------------------------------- 1 | 1 2 | 00:00:00,000 --> 00:00:00,367 3 | 4 | 5 | 2 6 | 00:00:00,367 --> 00:00:02,950 7 | SPEAKER: Now that we've created 8 | our dictionary data structure, 9 | 10 | 3 11 | 00:00:02,950 --> 00:00:07,640 12 | it's time to free up all of that memory 13 | that we had previously allocated. 14 | 15 | 4 16 | 00:00:07,640 --> 00:00:10,080 17 | So how does one free a linked list? 18 | 19 | 5 20 | 00:00:10,080 --> 00:00:11,810 21 | It might look something like this. 22 | 23 | 6 24 | 00:00:11,810 --> 00:00:14,643 25 | Here I follow the same convention 26 | that I've used throughout the walk 27 | 28 | 7 29 | 00:00:14,643 --> 00:00:17,290 30 | through where the node 31 | pointer, called head, 32 | 33 | 8 34 | 00:00:17,290 --> 00:00:21,020 35 | refers to the very first 36 | node in a linked list. 37 | 38 | 9 39 | 00:00:21,020 --> 00:00:23,870 40 | The code to free a linked list 41 | might look something like this. 42 | 43 | 10 44 | 00:00:23,870 --> 00:00:27,870 45 | Here I assign a new node 46 | pointer, called cursor, to head. 47 | 48 | 11 49 | 00:00:27,870 --> 00:00:30,690 50 | Remember that following the 51 | convention of this walk through, 52 | 53 | 12 54 | 00:00:30,690 --> 00:00:34,430 55 | I've used head to refer to the node 56 | pointer that points to the very 57 | 58 | 13 59 | 00:00:34,430 --> 00:00:36,930 60 | first element in a linked list. 61 | 62 | 14 63 | 00:00:36,930 --> 00:00:41,170 64 | For your hashtable, it might 65 | be named something different. 66 | 67 | 15 68 | 00:00:41,170 --> 00:00:45,930 69 | Then I enter a loop that advances 70 | as long as the cursor is not null. 71 | 72 | 16 73 | 00:00:45,930 --> 00:00:50,160 74 | Within that, I create a temporary node 75 | pointer, initially pointing to cursor. 76 | 77 | 17 78 | 00:00:50,160 --> 00:00:54,280 79 | I advance the cursor and then 80 | free that temporary node pointer. 81 | 82 | 18 83 | 00:00:54,280 --> 00:00:55,880 84 | What does that look like? 85 | 86 | 19 87 | 00:00:55,880 --> 00:00:58,360 88 | Well I leave it to you to 89 | follow through this example, 90 | 91 | 20 92 | 00:00:58,360 --> 00:01:03,120 93 | erasing and creating arrows as necessary 94 | to see how this method of freeing 95 | 96 | 21 97 | 00:01:03,120 --> 00:01:06,640 98 | will ensure that no 99 | node is left un-freed. 100 | 101 | 22 102 | 00:01:06,640 --> 00:01:09,320 103 | If instead of a 104 | hashtable or linked list, 105 | 106 | 23 107 | 00:01:09,320 --> 00:01:12,430 108 | you've decided to implement 109 | your dictionary as a try, 110 | 111 | 24 112 | 00:01:12,430 --> 00:01:15,120 113 | then you'll unload from 114 | the bottom to the top. 115 | 116 | 25 117 | 00:01:15,120 --> 00:01:19,440 118 | What I mean by this is that you can 119 | travel to the lowest possible node, 120 | 121 | 26 122 | 00:01:19,440 --> 00:01:21,940 123 | from there you can free all 124 | of those pointers and children 125 | 126 | 27 127 | 00:01:21,940 --> 00:01:24,590 128 | because you know they're not 129 | linking to anything else. 130 | 131 | 28 132 | 00:01:24,590 --> 00:01:27,690 133 | From there, you can then 134 | go up to the parent node 135 | 136 | 29 137 | 00:01:27,690 --> 00:01:31,640 138 | and backtrack upwards that way, freeing 139 | all of the elements in each children 140 | 141 | 30 142 | 00:01:31,640 --> 00:01:34,340 143 | array until you hit the root node. 144 | 145 | 31 146 | 00:01:34,340 --> 00:01:36,820 147 | If you get stuck, remember 148 | to take pen to paper 149 | 150 | 32 151 | 00:01:36,820 --> 00:01:39,460 152 | and draw out your try data 153 | structure in whichever 154 | 155 | 33 156 | 00:01:39,460 --> 00:01:41,670 157 | schematic makes most sense to you. 158 | 159 | 34 160 | 00:01:41,670 --> 00:01:45,820 161 | And there, you can ensure that following 162 | your code, you free all of the nodes 163 | 164 | 35 165 | 00:01:45,820 --> 00:01:47,470 166 | that you've ever created. 167 | 168 | 36 169 | 00:01:47,470 --> 00:01:50,600 170 | If you've chosen to go with 171 | a try for a data structure, 172 | 173 | 37 174 | 00:01:50,600 --> 00:01:54,790 175 | then I challenge you to look at 176 | recursion for an elegant implementation 177 | 178 | 38 179 | 00:01:54,790 --> 00:01:56,980 180 | of the unload function. 181 | 182 | 39 183 | 00:01:56,980 --> 00:02:01,130 184 | Finally, whether or not you've 185 | chosen a hashtable or a try, 186 | 187 | 40 188 | 00:02:01,130 --> 00:02:03,420 189 | make sure to run 190 | valgrind, which will check 191 | 192 | 41 193 | 00:02:03,420 --> 00:02:06,580 194 | to make sure that all of the memory 195 | that you've allocated in your program, 196 | 197 | 42 198 | 00:02:06,580 --> 00:02:08,460 199 | you've also freed by the end. 200 | 201 | 43 202 | 00:02:08,460 --> 00:02:11,980 203 | If valgrind gives you the 204 | OK, then you're good to go 205 | 206 | 44 207 | 00:02:11,980 --> 00:02:14,810 208 | and you've successfully 209 | unloaded your dictionary. 210 | 211 | 45 212 | 00:02:14,810 --> 00:02:17,800 213 | My last couple tips to you 214 | before you go out and code, 215 | 216 | 46 217 | 00:02:17,800 --> 00:02:20,930 218 | is to try make it easier 219 | on yourself to debug. 220 | 221 | 47 222 | 00:02:20,930 --> 00:02:23,850 223 | Pass in a smaller dictionary 224 | to speller instead. 225 | 226 | 48 227 | 00:02:23,850 --> 00:02:27,820 228 | By default, speller will run 229 | with the large dictionary file. 230 | 231 | 49 232 | 00:02:27,820 --> 00:02:30,100 233 | But also, try passing 234 | in the small dictionary 235 | 236 | 50 237 | 00:02:30,100 --> 00:02:32,530 238 | file provided in the distribution code. 239 | 240 | 51 241 | 00:02:32,530 --> 00:02:36,640 242 | Or you can even make your own 243 | dictionary and your own input text file. 244 | 245 | 52 246 | 00:02:36,640 --> 00:02:41,900 247 | Perhaps, use the words that we talked 248 | about today, fox, food, dog, and do. 249 | 250 | 53 251 | 00:02:41,900 --> 00:02:45,150 252 | Finally, pen and paper are 253 | going to be your best friend. 254 | 255 | 54 256 | 00:02:45,150 --> 00:02:47,980 257 | Try drawing out your 258 | dictionary as you create it, 259 | 260 | 55 261 | 00:02:47,980 --> 00:02:51,570 262 | load it, check it, and finally, unload. 263 | 264 | 56 265 | 00:02:51,570 --> 00:02:55,900 266 | My name is Zamyla, and this was speller. 267 | 268 | 57 269 | 00:02:55,900 --> 00:02:57,260 -------------------------------------------------------------------------------- /2016/es/lectures/chapters/README.md: -------------------------------------------------------------------------------- 1 | 2016 Spanish lecture chapters. 2 | -------------------------------------------------------------------------------- /2016/es/lectures/chapters/week0harvard.vtt: -------------------------------------------------------------------------------- 1 | WEBVTT 2 | 3 | 00:00:00.000 --> 00:01:58.000 4 | Esto es CS50. 5 | 6 | 00:01:58.000 --> 00:03:37.000 7 | Descripción del curso 8 | 9 | 00:03:37.000 --> 00:09:06.000 10 | Introducción al Binario 11 | 12 | 00:09:06.000 --> 00:12:05.000 13 | Luces binarias 14 | 15 | 00:12:05.000 --> 00:13:52.000 16 | ASCII 17 | 18 | 00:13:52.000 --> 00:15:32.000 19 | RGB 20 | 21 | 00:15:32.000 --> 00:21:57.000 22 | Tomando Asistencia 23 | 24 | 00:21:57.000 --> 00:27:59.000 25 | Buscando a Mike Smith 26 | 27 | 00:27:59.000 --> 00:30:55.000 28 | Un buen algoritmo 29 | 30 | 00:30:55.000 --> 00:36:58.000 31 | ¿Qué hay de nuevo? 32 | 33 | 00:36:58.000 --> 00:41:44.000 34 | CS50 Staff 35 | 36 | 00:41:44.000 --> 00:43:44.000 37 | Eventos 38 | 39 | 00:43:44.000 --> 00:45:46.000 40 | Staff Video 41 | 42 | 00:45:46.000 --> 00:51:34.000 43 | Introducción a Scratch 44 | 45 | 00:51:34.000 --> 00:56:23.000 46 | Oscartime 47 | 48 | 00:56:23.000 --> 01:00:32.000 49 | El Editor de Scratch 50 | 51 | 01:00:32.000 --> 01:02:39.000 52 | Movimientos en Scratch 53 | 54 | 01:02:39.000 --> 01:04:55.000 55 | Contando ovejas 56 | 57 | 01:04:55.000 --> 01:05:37.000 58 | Acaricia al gato 59 | 60 | 01:05:37.000 --> 01:06:16.000 61 | No acaricies al gato 62 | 63 | 01:06:16.000 --> 01:08:01.000 64 | hilos 65 | 66 | 01:08:01.000 --> 01:09:43.000 67 | hi hi hi 68 | 69 | 01:09:43.000 --> 01:11:01.000 70 | Pokémon Go 71 | 72 | 01:11:01.000 --> 01:12:06.000 73 | cough-0 74 | 75 | 01:12:06.000 --> 01:13:08.000 76 | cough-2 77 | 78 | 01:13:08.000 --> 01:15:24.000 79 | cough-3 80 | 81 | 01:15:24.000 --> 01:17:28.000 82 | ¿Qué esperamos? 83 | 84 | 01:17:28.000 --> 01:18:40.000 85 | Outro 86 | -------------------------------------------------------------------------------- /2016/es/lectures/chapters/week0yale.vtt: -------------------------------------------------------------------------------- 1 | WEBVTT 2 | 3 | 00:00:00.000 --> 00:02:46.000 4 | Introducción 5 | 6 | 00:02:46.000 --> 00:06:50.000 7 | Esto es CS50. 8 | 9 | 00:06:50.000 --> 00:08:55.000 10 | Resolución de Problemas 11 | 12 | 00:08:55.000 --> 00:15:48.000 13 | Introducción al Binario 14 | 15 | 00:15:48.000 --> 00:18:03.000 16 | ASCII 17 | 18 | 00:18:03.000 --> 00:20:10.000 19 | RGB 20 | 21 | 00:20:12.000 --> 00:27:40.000 22 | Buscando a Mike Smith 23 | 24 | 00:27:38.000 --> 00:32:03.000 25 | Buenos algoritmos 26 | 27 | 00:32:03.000 --> 00:40:27.000 28 | Descripción del curso 29 | 30 | 00:40:27.000 --> 00:45:26.000 31 | Presentación del Staff 32 | 33 | 00:45:26.000 --> 00:47:18.000 34 | Videos del Staff 35 | 36 | 00:47:15.000 --> 00:51:43.000 37 | Introducción a Scratch 38 | 39 | 00:51:43.000 --> 00:53:13.000 40 | El Editor de Scratch 41 | 42 | 00:53:13.000 --> 00:56:18.000 43 | Meowing 44 | 45 | 00:56:18.000 --> 00:59:25.000 46 | En movimiento 47 | 48 | 00:59:25.000 --> 01:00:40.000 49 | Acaricia al gato 50 | 51 | 01:00:40.000 --> 01:02:40.000 52 | hilos 53 | 54 | 01:02:40.000 --> 01:03:22.000 55 | eventos 56 | 57 | 01:03:22.000 --> 01:04:12.000 58 | hi hi hi 59 | 60 | 01:04:12.000 --> 01:07:05.000 61 | Pokémon Go 62 | 63 | 01:07:05.000 --> 01:12:12.000 64 | Juego más difícil de Ivy (Remix) 65 | 66 | 01:12:12.000 --> 01:12:44.000 67 | Palabras de clausura 68 | 69 | 01:12:44.000 --> 01:14:40.000 70 | Teaser Video 71 | 72 | 01:14:40.000 --> 01:15:54.000 73 | Outro -------------------------------------------------------------------------------- /2016/es/lectures/subtitles/README.md: -------------------------------------------------------------------------------- 1 | 2016 Spanish lecture subtitles. 2 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # CS50 Translate 2 | 3 | CS50 provides subtitle tracks, chapter files and other learning materials in American English. These resources are made open and available to be translated into other languages by the community. If you would like to help us on our mission to introduce people all over the world to computer science, and are fluent in a language other than English, then help us out by joining our growing community of translators. 4 | 5 | We currently support translations from English to: 6 | 7 | - Arabic 8 | - Spanish 9 | - Urdu 10 | 11 | These are the languages we currently have moderators for. Moderators are volunteers who are in charge of proofing and organizing translations of resources in a given language. If you would like to see your language added to the list and are comfortable taking on the role of moderator for your language, then please get in touch with us at translate@cs50.harvard.edu. 12 | 13 | ## Getting Started 14 | 15 | ### Setup 16 | 17 | 1. Make sure you have Git installed on your computer. 18 | 2. Open Terminal for Mac; or PowerShell or Git Bash for Windows. 19 | 3. Clone the repository:
20 | ``` 21 | git clone git@github.com:cs50/tracks.git 22 | ``` 23 | 24 | ### Contributing 25 | 26 | 1. Make sure you have the latest version of the repository:
27 | ``` 28 | git checkout master 29 | ``` 30 |
31 | ``` 32 | git pull origin master 33 | ``` 34 | 2. Create your feature branch:
35 | ``` 36 | git checkout -b new-feature 37 | ``` 38 | 3. Go to the file you wish to translate, and make edits. 39 | 4. Once you're done making changes, commit your changes:
40 | ``` 41 | git commit -am "Translates text in [x] section" 42 | ``` 43 | 5. Push to the branch:
44 | ``` 45 | git push origin new-feature 46 | ``` 47 | 6. Submit a pull request at https://github.com/cs50/tracks/pulls. 48 | 49 | ## License 50 | 51 | CS50's content is licensed by David J. Malan of Harvard University under a [Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License](https://creativecommons.org/licenses/by-nc-sa/3.0/). 52 | -------------------------------------------------------------------------------- /SUMMARY.md: -------------------------------------------------------------------------------- 1 | # Summary 2 | 3 | * [2016](2016/README.md) 4 | * [English](2016/en/README.md) 5 | * [Lecture Subtitles](2016/en/lectures/README.md) 6 | * [Week 0](2016/en/lectures/week0.md) 7 | * [Week 1](2016/en/lectures/week1.md) 8 | * [Week 2](2016/en/lectures/week2.md) 9 | * [Week 3](2016/en/lectures/week3.md) 10 | * [Week 4](2016/en/lectures/week4.md) 11 | * [Week 5](2016/en/lectures/week5.md) 12 | * [Sections](2016/en/sections/README.md) 13 | * [Walkthroughs](2016/en/walkthroughs/README.md) 14 | * [Spanish](2016/es/README.md) 15 | * [Arabic](2016/ar/README.md) 16 | --------------------------------------------------------------------------------