Skip to content
This repository was archived by the owner on Aug 20, 2020. It is now read-only.

Commit de97a62

Browse files
committed
Fix images
1 parent e80b53d commit de97a62

File tree

2 files changed

+8
-8
lines changed

2 files changed

+8
-8
lines changed

curriculum/3/notes/index.md

+5-5
Original file line numberDiff line numberDiff line change
@@ -48,9 +48,9 @@
4848
* After we write a program from a problem set, and have tested it ourselves with a few inputs, we can type `check50 cs50/problems/2019/ap/hello`. The `cs50/problems/2019/ap/hello` is an indicator for the program specification that `check50` should check, and once we run that command, we'll see `check50` uploading our code and checking it.
4949
* We can also now use a tool called a *debugger*, built into the CS50 IDE.
5050
* After we compile our code, we can run `debug50 ./hello`, which will tell us to set a breakpoint first. A *breakpoint* indicates a line of code where the debugger should pause our program, until we choose to continue it. For example, we can click to the left of a line of our code, and a red circle will appear:<br>
51-
![code editor with red icon next to line 6 of code](/breakpoint.png)
51+
![code editor with red icon next to line 6 of code](breakpoint.png)
5252
* Now, if we run `debug50 ./hello` again, we'll see the debugger panel open on the right:<br>
53-
![debugger panel with controls, variables](/debugger_panel.png)
53+
![debugger panel with controls, variables](debugger_panel.png)
5454
* We see that the variable we made, `name`, is under the `Local Variables` section, and see that there's a value of `0x0` (which is `null`), and a type of `string`, as we expected.
5555
* Our breakpoint has paused our program _before_ line 6, so to continue, we have a few controls in the debugger panel. The blue triangle will continue our program until we reach another breakpoint. The curved arrow to its right will "step over" the line, running it and pausing our program again immediately after. The arrow pointing downward will "step into" the line, if there is a function being called. And the arrow pointing up and to the right will "step out" of a function, if we are in one.
5656
* So, we'll use the curved arrow to run the next line, and see what changes after. After we type in our name, we'll see that the `name` variable is also updated in the debugger.
@@ -107,10 +107,10 @@
107107
* Hmm, no matter what we type in for our strings, our program thinks they are different.
108108
* It turns out, `string` is not actually a data type in C. The word "string" is common in computer science, but there is no way to store strings in C. Instead, we defined that type in the CS50 Library.
109109
* Recall that strings are just arrays of characters, so when we ran our `compare1` program, we got two strings as input from the user, and those might be stored in memory as the following:<br>
110-
!["Brian\0" and "Veronica\0" in different grids](/strings.png)
110+
!["Brian\0" and "Veronica\0" in different grids](strings.png)
111111
* Each character is in one byte, and somewhere we have bytes in memory containing the values for each of string.
112112
* It turns out, each byte in memory has a numeric location, or *address*. For example, the character `B` might have the address 100, and `V` might have ended up in `900` (depending on what parts of memory were available, or free):<br>
113-
!["Brian\0" and "Veronica\0" in different grids, with each grid, or byte in memory, labelled](/strings_with_addresses.png)
113+
!["Brian\0" and "Veronica\0" in different grids, with each grid, or byte in memory, labelled](strings_with_addresses.png)
114114
* Notice that, since each string is an array of characters, each character within the array has consecutive addresses, since they are stored next to each other in memory. But the strings themselves might have very different addresses.
115115
* So, `get_string` actually returns just the address of the first character of the string. (We can tell where it ends by looking for the `null` character, `\0`.) Now, we can infer that comparing two "strings" actually just compares two addresses (which will always be different, since `get_string` stores the input in a new place each time), even if the characters stored at those addresses are the same.
116116
* Other data types in C, such as `int`s or `float`s, are generally passed and stored as their values, since they are always a fixed number of bytes. Strings, on the other hand, are passed as their addresses, since they could be really long.
@@ -304,7 +304,7 @@
304304
* We get a string `s`, and copy the value of `s` into `t`. Then, we capitalize the first letter in `t`.
305305
* But when we run our program, we see that both `s` and `t` are now capitalized.
306306
* Since we set `s` and `t` to the same values, they're actually pointers to the same character, and so we capitalized the same character:<br>
307-
![s and t variables pointing to the same string](/pointers.png)
307+
![s and t variables pointing to the same string](pointers.png)
308308
* To actually make a copy of a string, we have to do a little more work:
309309
```c
310310
#include <cs50.h>

curriculum/4/notes/index.md

+3-3
Original file line numberDiff line numberDiff line change
@@ -109,7 +109,7 @@
109109
* We can do the opposite, and ask for just enough memory for one element, like one integer, at a time. But they might be stored anywhere in the heap, so we need a way to link each element to the next, via a stored pointer.
110110
* With this data structure, called a linked list, we lose the ability to randomly access elements. For example, we can no longer access the 5th element of the list by calculating where it is, in constant time. (Since we know arrays store elements back-to-back, we can add 1, or 4, or the size of our element, to calculate addresses.) Instead, we have to follow each element, one at a time.
111111
* And we create a linked list by allocating, for each element, enough memory for both the value, and a pointer to the next element. We'll call these nodes:<br>
112-
![linked list with node at address 100 with value 42 and pointer to address 475, which has value 50 and pointer to address 150, which has value 13 and pointer to NULL](/linked_list.png)
112+
![linked list with node at address 100 with value 42 and pointer to address 475, which has value 50 and pointer to address 150, which has value 13 and pointer to NULL](linked_list.png)
113113
* We have three nodes at various addresses in memory, `100`, `150`, and `475`. Each node has the value we want to store, and also a pointer to the next node. The final node has a pointer of `NULL`, indicating the end of our linked list.
114114
* In code, we might create our own struct called `node`, with an `int` and a pointer to the next `node` called `next`:
115115
```c
@@ -314,7 +314,7 @@
314314
* We, as humans, might make smaller lists where each person whose name starts with "A" will be in one list, "B" in another, and so on. We can represent this concept with a *hash table*, where each value to be stored is _hashed_ by a _hash function_. The resulting _hash_ might be a number, and in this case might be `0` for a string that starts with `A`, `1` for a string that starts with `B`, and so on, but the important part is that we can use that number to index into some array. The array, in turn, will have a linked list for each letter of the alphabet (or more generally, a linked list for each _bucket_), and so this data structure is called a hash table.
315315
* Now, each linked list (in our example of strings) will only be, on average, 1/26th the size of a list with all the strings together. In the worst case, all the strings will end up in the same bucket (if they happen to start with the same letter), and we would have _O_(_n_) running time, like an unsorted array. We can also use a different hash function, which might distribute our elements more evenly. But in the real world, our running time is likely to be much lower with a hash table. And we can even have more buckets in our hash table, so each list is an even smaller proportion.
316316
* A *tree* is another data structure where each node points to two other nodes, one to the left (with a smaller value) and one to the right (with a larger value):<br>
317-
![tree with node 55 at top center, left arrow to 33 below, right arrow to 77 below; 33 has left arrow to 22 below, right arrow to 44 below; 77 has left arrow to 66 below, right arrow to 88 below](/tree.png)
317+
![tree with node 55 at top center, left arrow to 33 below, right arrow to 77 below; 33 has left arrow to 22 below, right arrow to 44 below; 77 has left arrow to 66 below, right arrow to 88 below](tree.png)
318318
* Now, we can easily do binary search, and since each node is pointing to another, we can also insert nodes into the tree without moving all of them around as we would have to in an array. Recursively searching this tree would look something like:
319319
```c
320320
typedef struct node
@@ -344,6 +344,6 @@
344344
}
345345
```
346346
* We can use another data structure called a *trie* (pronounced like "try", and is short for "retrieval"):<br>
347-
![array with blanks, and letters M, P, T; each letter points to another array, with blanks, and some letters that each point to other arrays and letters in them](/trie.png)
347+
![array with blanks, and letters M, P, T; each letter points to another array, with blanks, and some letters that each point to other arrays and letters in them](trie.png)
348348
* Imagine we want to store a dictionary of words efficiently, and be able to access each one in constant time. A trie is like a tree, but each node is an array. Each array will have each letter, A-Z, stored. For each word, the first letter will point to an array, where the next valid letter will point to another array, and so on, until we reach something indicating the end of a valid word. If our word isn't in the trie, then one of the arrays won't have a pointer or terminating character for our word.
349349
* In our upcoming problem set, we'll use what we've learned about pointers and data structures to implement a spell-checking program, and gain an understanding of how something that might work at a low level.

0 commit comments

Comments
 (0)