|
"outfile.txt" is basically the input file that has the binary string of 1s and 0s, and that has to be decoded using the Huffman Algorithm that I made.
|
|
|
|
|
did you see the part about ios::ate?
|
|
|
|
|
Actually, for me to set the ios::ate means that I'm getting first the size of the file; then, I implement seekg(0, ios::beg) to start getting the values. It does work in the encoding part pf my program, where I get first the size of the file, seek back and then use for loop (with the limit of the size) to get each character.
|
|
|
|
|
Francis Paran wrote:
curNode = ithNode->rightCursor;
As you haven't posted the definition of your Tree I can only make assumptions, but shouldn't this be
curNode = ithNode->rightCursor->value; ?
|
|
|
|
|
No, because curNode just points to a node, in which a char variable can get its value.
|
|
|
|
|
Ah, of course. Somehow I was mixing this up with the cout line above, thinking this was also meant to be sent to cout. You're correct.
|
|
|
|
|
Sadly, moving the curNode to point to the right child (with the else statement) will always end up gettin 'e' for all the values being decoded. Any ideas why this is so?
|
|
|
|
|
Well, all I see is your decoding - not the structure of your tree nor the program that created it. What I find odd is that you treat the entire file as one single code - that would require your tree to have at least as many levels as the file has '0'-characters. Surely that can't be correct?
And what happens when you reach the end of your branching, i. e. ithNode->rightcursor==0?
As I was writing this, something else struck me: you never advance ithNode, so your curNode will always be either ithNode or ithNode->rightCursor, and your cout line will always output either ithNode->leftCursor->value or ithNode->rightCursor->leftCursor->value. More to the point, the moment you encounter the first character not equal to '0', all following characters being output will be ithNode->rightCursor->leftCursor->value. My educated guess is that this character is 'e'. 
|
|
|
|
|
Okay, that was a mistake on my part that I just found out yesterday. What I did was after finding a '1' in the file then output the character value of the left cursor of the node that curNode points at that point (assuming it has gone to many right cursors for every '0' found), and then let curNode point back at the ithNode which is just the front node of the queue. However, it was still 'e' that it prints out on the screen.
You are actually right at your point that 'e' will always come out, since 'e' is 01 at the encoding and that I always move one right cursor and a left cursor if it's '1' for all the characters in the file. Any ideas in how make this better?
|
|
|
|
|
I suspect that you need to replace
curNode = ithNode->rightCursor; with
curNode = curNode->rightCursor; but without knowing your tree structure that is just a guess. And that would still leave you with the problem that the whole file will be considered a single code, and the tree will have to be deep enough that it actually can descend at least as many times as there are '0' characters.
Are there really no separators in that file? Or are your codes supposed to have a fixed length? You need something to decide when the end of the code for the current 'word' is reached.
Or maybe when you reach the end of the tree branching (i. e. curNode->rightCursor==0), does that mean you have reached the end of the code and you have to take the value of the current node instead? I don't know Huffman encoding from the top of my head, but if it's a varied length encoding, this may be it.
|
|
|
|
|
In the file, every binary string representation of a character has to end up with a '1'. Moreover, the Huffman Coding tree satisfies Prefix coding where no one bit of a character code is a bit of another. Huffman coding is easier to read because all the characters that are more occurring have less binary bits than those that are least occurring; they are not of a fixed length, so decoding must get easily the characters that are at the shortest path from the root (based on how the bit strings will have the '1' in the end) than those that are way down deep at the tree.
With the curNode, you're definitely right. I should have assigned curNode to point to the right cursor from where it was at, my bad.
modified on Wednesday, May 4, 2011 12:20 PM
|
|
|
|
|
Francis Paran wrote: size = codeIn.tellg();
I suspect size is 0, since the file pointer has not moved.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather
|
|
|
|
|
Unless it's at the end of the file, which I did with the input stream, then yes the size will always be zero. I don't think that I'm having some trouble with the size; it's just that I'm getting 'e' everytime I try to decode each of the characters in the file.
|
|
|
|
|
I've never used ios::ate before so I did not realize it set the stream's position indicator to the end of the stream. My bad.
Francis Paran wrote: codeIn>>noskipws>>charGet[i];
...
if (bitCode[j] == '1')
Have you set a breakpoint on these two lines to verify charGet[i] and bitCode[j] are what you expect?
What are you populating curNode->leftCursor->value with?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather
|
|
|
|
|
The thing is that every bit string representation of a character always ends up with a '1'. Whenever '1' is found in the string, the program should print out leftCursor->value of the node that curNode points so far. Another thing to consider is that every leftCursor of a node in the Huffman Queue (remember it's two queues and not a tree) points to a node of the first queue that contains a character value, which therefore makes every rightCursor of a node a pointer to the next node of the second queue.
|
|
|
|
|
Francis Paran wrote: The thing is that every bit string representation of a character always ends up with a '1'. Whenever '1' is found in the string, the program should print out leftCursor->value of...
Hence my suggestion to step through the code using the debugger.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather
|
|
|
|
|
Okay, I think I know now what I did wrong. It's the one that generates the Huffman tree before encoding the characters into their unique code, because I don't have the function to sort the nodes in the first queue after putting a new node that has the sum of the two smallest nodes in the first queue into the second queue (as another way of implementing besides a priority queue Huffman coding). Therefore, what happens is that 01 in a bit string will always print out 'e' in the decoding part. Below is the function that generates the two queue-cursor Huffman Coding Tree:
void generateHuffman (Queue& q1, Queue& q2)
{
QueueNode *leftChild, *rightChild, *tempNode;
char tempChar = q1.frontNode()->value;
q1.enqueueChar(tempChar, q1.dequeue());
q2.enqueue(q1.front()+q1.back());
rightChild = q1.backNode();
tempChar = q1.frontNode()->value;
q1.enqueueChar(tempChar, q1.dequeue());
leftChild = q1.backNode();
q2.setCursor(leftChild, rightChild);
while (q1.back() <= q1.front())
{
q2.enqueue( q1.front()+q2.front() );
tempNode = q2.backNode();
q2.enqueue(q2.dequeue());
tempNode->rightCursor = q2.backNode();
tempChar = q1.frontNode()->value;
q1.enqueueChar(tempChar, q1.dequeue());
tempNode->leftCursor = q1.backNode();
while( q2.frontNode() != tempNode)
q2.enqueue(q2.dequeue());
tempNode = NULL;
}
}
I was trying to have a compare function for this, so that I can use the STL sort the way I did with the list of character frequencies in an array. What do you think. Is there any way that this can be better improved. Please help, thank you.
|
|
|
|
|
How would i iterate over CStringW characters?
I need the equivalent of this:
void func(wchar_t *Stuff)
{
int len = wcslen(Stuff);
for(int i = 0; i < len; i++)
{
std::wcout << Stuff[i] << std::endl;
}
}
Thanks.
011011010110000101100011011010000110100101101110
0110010101110011
|
|
|
|
|
Alright, solved it.
for(int i = 0; ; i++)
{
wchar_t ch = pString.GetAt(i);
if(ch == 0) break;
}
011011010110000101100011011010000110100101101110
0110010101110011
|
|
|
|
|
operator[] is defined for CString, (CStringW and CStringA), so there should be no problem using that either.
|
|
|
|
|
Hi,
How can I copy text on clipboard?
|
|
|
|
|
Are you using MFC? If affirmative see the SetClipboardData[^] API
You talk about Being HUMAN. I have it in my name
AnsHUMAN
|
|
|
|
|
_AnsHUMAN_ wrote: Are you using MFC? If affirmative see the SetClipboardData[^] API
With SetClipboardData(), it matters not if MFC is being used.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather
|
|
|
|
|
|
I need to know , for CListCtrlEx::OnNMCustomdraw(...) if list control have LVS_EX_FULLROWSELECT AND LVS_EX_GRIDLINES extended style ... my question is , there is a method to find that in single line of code ? I try this :
GetExtendedStyle() & LVS_EX_FULLROWSELECT & LVS_EX_GRIDLINES
but is stupid .
And one more thing : it's a good ideea to check that ( have 2 extended style ) in OnNMCustomdraw(...) in above style ? Or it be good thing to set up a variable that know if list control have both extended style ?
Thnak you .
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
