Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Your approach (write the number of encoded bytes the to the file) is a perfectly reasonable approach. If you want to try a different avenue, you could consider inventing a new "pseudo-EOF" character that marks the end of the input (I'll denote it as &square;). Whenever you want to compress a string <em>s</em>, you instead compress the string <em>s</em>&square;. This means that when you build up your encoding tree, you would include one copy of the &square; character so that you have a unique encoding for &square;. Then, when you write out the string to the file, you would write out the bits characters of the string as normal, then write out the bit pattern for &square;. If there are leftover bits, you can just leave them set arbitrarily.</p> <p>The advantage to this approach is that as you decode the file, if at any point you find the &square; character, you can immediately stop decoding bits because you know that you have hit the end of the file. This does not require you to store the number of bytes that were written out anywhere - the encoding implicitly marks its own endpoint.</p> <p>The disadvantage to this setup is that it might increase the length of the bit patterns used by certain characters, since you will need to assign a bit pattern to &square; in addition to all the other characters.</p> <p>I teach an introductory programming course and we use Huffman encoding as one of our assignments. We have students use the above approach, since it's a bit easier than having to write out the number of bits or bytes before the file contents. For more details, you could take a look at <a href="http://www.stanford.edu/class/archive/cs/cs106b/cs106b.1126/handouts/220%20Huffman%20Encoding.pdf" rel="noreferrer">this handout</a> or <a href="http://www.stanford.edu/class/archive/cs/cs106b/cs106b.1126/lectures/22/Slides22.pdf" rel="noreferrer">these lecture slides</a> from the course.</p> <p>Hope this helps!</p>
    singulars
    1. This table or related slice is empty.
    1. POLast byte in Huffman compression
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. UStemplatetypedef
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POLast byte in Huffman compression
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThere really isn't a disadvantage, since you can prove that this won't take more bits than encoding the length.
      singulars
      1. PO
      1. USMark Adler
    2. CO@MarkAdler- Do you have a reference for that? I have often wondered this, but I've never seen a formal proof.
      singulars
      1. PO
      1. UStemplatetypedef
    3. COI don't remember off-hand where I saw that. I'll look for it.
      singulars
      1. PO
      1. USMark Adler
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload