From 3fa7a5b8a7658ed883719aed6930a47bd3a6b980 Mon Sep 17 00:00:00 2001 From: Gregor Anzelj Date: Fri, 11 May 2018 23:29:37 +0200 Subject: [PATCH 1/4] Fix uncorrect answer for challenge --- text/en/chapters/data-representation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/en/chapters/data-representation.md b/text/en/chapters/data-representation.md index 21e445adce..bd6c4e4d9c 100644 --- a/text/en/chapters/data-representation.md +++ b/text/en/chapters/data-representation.md @@ -426,7 +426,7 @@ It is really useful to know roughly how many bits you will need to represent a c {panel type="spoiler" summary="Answers for above challenge"} 1. b (actually, 3 bits is enough as it gives 8 values, but amounts that fit evenly into 8-bit bytes are easier to work with) 2. c (32 bits is slightly too small, so you will need 64 bits) -3. c (This is a challenging question, but one a database designer would have to think about. There's about 94,000 km of roads in NZ, so if the average length of a road was 1km, there would be too many roads for 16 bits. Either way, 32 bits would be a safe bet.) +3. b (This is a challenging question, but one a database designer would have to think about. There's about 94,000 km of roads in NZ, so if the average length of a road was 1km, there would be too many roads for 16 bits. Either way, 32 bits would be a safe bet.) 4. d (Even 64 bits is not enough, but 128 bits is plenty! Remember that 128 bits isn't twice the range of 64 bits.) {panel end} From 96ba73852ae4bf8abffb28e0041546dfad736325 Mon Sep 17 00:00:00 2001 From: Gregor Anzelj Date: Mon, 21 May 2018 22:02:32 +0200 Subject: [PATCH 2/4] Add chinese character description --- text/en/chapters/data-representation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/en/chapters/data-representation.md b/text/en/chapters/data-representation.md index bd6c4e4d9c..5945ab1191 100644 --- a/text/en/chapters/data-representation.md +++ b/text/en/chapters/data-representation.md @@ -878,7 +878,7 @@ The character **$** in UTF-32 would be: 00000000 00000000 00000000 00100100 ``` -And the character **犬** in UTF-32 would be: +And the character **犬** (dog in Chinese) in UTF-32 would be: ``` 00000000 00000000 01110010 10101100 ``` From 6237932e5e7bc47a4070f93ffef294d84bc9ebe0 Mon Sep 17 00:00:00 2001 From: Gregor Anzelj Date: Mon, 21 May 2018 22:42:41 +0200 Subject: [PATCH 3/4] Some typo fixes --- text/en/chapters/coding-compression.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/text/en/chapters/coding-compression.md b/text/en/chapters/coding-compression.md index 25ea092fb3..67c368b6ad 100644 --- a/text/en/chapters/coding-compression.md +++ b/text/en/chapters/coding-compression.md @@ -254,8 +254,8 @@ The purpose of Huffman coding is to take a set of "symbols" (which could be char It's normally presented as a way of compressing textual documents, and while it can do that reasonably well, it works much better in combination with Ziv-Lempel coding (see below). But let's start with a very simple textual example. -This example language uses only 4 different characters, and yet is incredibly important to us: it's the language used to represent DNA, which is made up of sequences of four characters A, C, G and T). -For example, the 4.6 million characters representing an E.coli DNA sequence happens to start with: +This example language uses only 4 different characters, and yet is incredibly important to us: it's the language used to represent DNA, which is made up of sequences of four characters A, C, G and T. +For example, the 4.6 million characters representing an *E.coli* DNA sequence happens to start with: ``` agcttttcattct @@ -353,7 +353,7 @@ digraph G { } {comment end} -To decode something using this structure (e.g. the code 0100110011110001011001 above), start at the top, and choose a branch based each successive bit in the coded file. The first bit is a 0, so we follow the left branch, then the 1 branch, then the 0 branch, which leads us to the letter a. +To decode something using this structure (e.g. the code 0100110011110001011001 above), start at the top, and choose a branch based each successive bit in the coded file. The first bit is a 0, so we follow the left branch, then the 1 branch, then the 0 branch, which leads us to the letter "a". After each letter is decoded, we start again at the top. The next few bits are 011..., and following these labels from the start takes us to "g", and so on. The tree makes it very easy to decode any input, and there's never any confusion about which branch to follow, and therefore which letter to decode each time. From 74340ac876fccef5b358d3dba1e83f147a94ac22 Mon Sep 17 00:00:00 2001 From: Gregor Anzelj Date: Mon, 21 May 2018 22:56:27 +0200 Subject: [PATCH 4/4] Some typo fixes --- text/en/chapters/coding-compression.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/text/en/chapters/coding-compression.md b/text/en/chapters/coding-compression.md index 25ea092fb3..67c368b6ad 100644 --- a/text/en/chapters/coding-compression.md +++ b/text/en/chapters/coding-compression.md @@ -254,8 +254,8 @@ The purpose of Huffman coding is to take a set of "symbols" (which could be char It's normally presented as a way of compressing textual documents, and while it can do that reasonably well, it works much better in combination with Ziv-Lempel coding (see below). But let's start with a very simple textual example. -This example language uses only 4 different characters, and yet is incredibly important to us: it's the language used to represent DNA, which is made up of sequences of four characters A, C, G and T). -For example, the 4.6 million characters representing an E.coli DNA sequence happens to start with: +This example language uses only 4 different characters, and yet is incredibly important to us: it's the language used to represent DNA, which is made up of sequences of four characters A, C, G and T. +For example, the 4.6 million characters representing an *E.coli* DNA sequence happens to start with: ``` agcttttcattct @@ -353,7 +353,7 @@ digraph G { } {comment end} -To decode something using this structure (e.g. the code 0100110011110001011001 above), start at the top, and choose a branch based each successive bit in the coded file. The first bit is a 0, so we follow the left branch, then the 1 branch, then the 0 branch, which leads us to the letter a. +To decode something using this structure (e.g. the code 0100110011110001011001 above), start at the top, and choose a branch based each successive bit in the coded file. The first bit is a 0, so we follow the left branch, then the 1 branch, then the 0 branch, which leads us to the letter "a". After each letter is decoded, we start again at the top. The next few bits are 011..., and following these labels from the start takes us to "g", and so on. The tree makes it very easy to decode any input, and there's never any confusion about which branch to follow, and therefore which letter to decode each time.