assets/developer-notes/stephanie-gawroriski/2016/03/12.mkd

   1 # 2016/03/12
   2
   3 ## 00:03
   4
   5 I get it, I am only checking one side in grow, I need to handle more of it.
   6
   7 ## 00:29
   8
   9 This time I get 'X' (88) instead of 'T'.
  10
  11 ## 10:56
  12
  13 T is 0h54 or 0b1010100. And X is 0b10110000 or 0h58. So I am pretty much a bit
  14 off by a single bit being in the wrong location. These are huffman codes so
  15 what I want is 0b10000100. What is something though is that I get that
  16 desired value when it is being read.
  17
  18 ## 11:02
  19
  20 So it appears my read value from readFirstInt is shifted too high it seems.
  21 Since I read 0b100 which is 4, but I instead return 8 from it.
  22
  23 ## 11:08
  24
  25 Changing the read to MSB fixes the issue. Normally I should not need to do it
  26 such as that, so the int conversion is lost somewhere.
  27
  28 ## 11:12
  29
  30 Actually I get it. I offer integers with LSB so they get added in that order,
  31 although when I get those integers they are read in the same order.
  32
  33 ## 11:15
  34
  35 When placing the lowest values are pushed in...
  36
  37         0011001001111
  38              ^^^^^^^^  -- 0b11110010
  39
  40 Then when reading the same order is used.
  41
  42 11 (0b1011) is added to become
  43
  44         11010000
  45
  46 Then 73 (0b1001001) is added
  47
  48         11010000 10010010
  49
  50 Then it is read as
  51
  52         11010000 10010010
  53         F
  54          TT
  55            HHhhh hhh
  56
  57 Reading first values results in 0b00100001, which is 33. However the lowest
  58 six bits get chopped off so it is instead read as: 0b0000100. This is 4.
  59
  60 ## 11:25
  61
  62 Thinking about it: 0b0010000 from lowest order. This is 16.
  63
  64 ## 11:31
  65
  66 Just going to go with reading it as MSB since it works.
  67
  68 ## 12:47
  69
  70 Must create the sliding window code and put bytes in there, also need to
  71 figure out how the sliding window reading works also.
  72
  73 ## 12:52
  74
  75 For reading the distance, I can use an algorithm for that. Each distance group
  76 appears in sets of 4 extra bits, the first 8 values have zero extra bits and
  77 represent single directories. So essentially instead of a lookup table I can
  78 use a linear sequence calculator to determine the distance to use. Then if
  79 there are any extra bits then they can be read.
  80
  81 ## 13:02
  82
  83 This graphing calculator I have is very handy during programming.
  84
  85 ## 13:19
  86
  87 And the distance and length handling was actually quite simple. What I need to
  88 do now is have the actual sliding window implemented.
  89
  90 ## 14:09
  91
  92 The distance starts at the furthest byte back, because otherwise it would not
  93 make sense.
  94
  95 ## 14:25
  96
  97 So now I have a working sliding window. I just need to figure out where an
  98 infinite loop occurs now, most likely at the end of the read.
  99
 100 ## 14:39
 101
 102 Was actually caused by the stop value being treated as an output byte value. So
 103 now the inflation algorithm passes and the resulting bytes are given. Now I
 104 need longer sequences that do other things. One thing I will need is random
 105 unique bytes that have nothing in common.
 106
 107 ## 14:46
 108
 109 Ok so I have a random data input which is completely terrible at compressing
 110 as it ends up being larger.
 111
 112 ## 21:12
 113
 114 Was doing lots of outside work before, rather tired.
 115
 116 ## 22:47
 117
 118 I believe the ZIP is reading data from the incorrect location.
 119