## converting 0d1221 to ob0110

19 posts / 0 new
Author
Message

guys, I'm looking to tease your brains for advice.  I have decimal numbers containing 1'sand 2's.  1 equals binary 0 and 2 equals binary 1.  So the decimal value of 0d122212 would become 0b011101.

Can you think of a quick/easy method to parse the data?

This topic has a solution.
Last Edited: Wed. Dec 11, 2019 - 02:26 PM

Do you only have to do this once or continuously? I think the different base means that you'll have to do a digit-wise operation. Should be really easy in Python.

Out of interest, how did this happen?

I need it to convert Huffman codes to binary.

For those that were wondering what Huffman Codes are:

https://en.wikipedia.org/wiki/Hu...

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

"The critical shortage here is not stuff, but time." - Johan Ekdahl

"Step N is required before you can do step N+1!" - ka7ehk

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

Subtract 1 from each digit in the number sequence.

Ross McKenzie, Melbourne Australia

How is the data presented? as binary numbers or as strings?. If as binary numbers, the old descending powers of 10 to isolate the digit, subtract 1 then shift bit. Rinse and repeat. Or if as strings, pick out a digit at a time then finagle it.

Not sure if this is what you had in mind, but I took a shot-

https://godbolt.org/z/y_3Cst

valusoft wrote:
Subtract 1 from each digit in the number sequence.
Short and simple - like it !

just to clarify, note the decimal representation of the number in decimal. 0d1122211 to a binary 0b0011100

So I'm going from unsigned int to unsigned char

You didn't answer Kartman's question - is it a string?

Top Tips:

1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
This reply has been marked as the solution.

Sketchy:

```char buffer[10];
uint8_t output = 0;

sprintf(buffer, "%08d", invalue);

for (int n = 0; n < strlen(buffer)) {
if (buffer[n] == '0') {
buffer[n] = '1';
}
output <<= 1;
output |= (buffer[n] - '1');
}```

say the invalue was 1122211 then after the sprintf() buffer should hold "01122211". The for() loop will iterate 8 times (it always will because of the %08 padding). If there are some leading 0's the first if() converts '0's to '1's. Each time round the loop the output is shifted one place left. As it starts with 0 the first iteration this does nothing. The first |= with n=0 will encounter the leading '1' that started as 0. it subtracts '1' from this to leave binary 0 and this is OR'd. Nothing changes, output is still 0. Next time round (and from now on) the if() does no character replacements as it's all 1's and 2's from now on. For the next two 1's the - '1' turns them into 0's so nothing yet is added to output. On the next time around it hits the first '2'. '2' - '1' is 1 so this time a 1 is |'d into the output. As always the result is <<= 1 each time round so this should now OR 11100 into the result. So you end with 11100 which is the right value for the 1122211 input.

This encoding (using 1 or 2 out of 0..9 in decimal positions) seems hugely inefficient! Wonder why the original encoding did not just put 0b0011100 into a single byte in the first place ??

awneil wrote:

You didn't answer Kartman's question - is it a string?

Hi awneil, I did.  its in decimal. i.e 0d1122112

Thanks clawson, I'll have a look at that.

that's still not clear whether it's a string of ASCII coded characters: - a '0', followed by a 'd', followed by a '1', followed by a '1', followed by a '2', etc

or an actual numeric value.

"0d" isn't a standard notation for anything.

Top Tips:

1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...

He means 1122112  or 0x111F40 or however you want to represent it. That is:

`uint32_t invalue = 1122112;`

As I say, using a uint32_t to hold a value that could have been encoded in 8 bits:

`uint8_t value = 0b00011001;`

just seems wasteful to me so I wonder what has chosen to use this whacky encoding in the first place?

If it had used uint8_ts the value would already be in the right binary pattern anyway.

clawson wrote:
I wonder what has chosen to use this whacky encoding in the first place?

Likewise!

Top Tips:

1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...

It was the easiest way to fill the Huffman tree using decimal notation.

really?

and why did it need to be decimal?

Top Tips:

1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...

Kind of the whole point of Huffman is to deal with messages that are not just 8 bit quantities. So for proper Huffman compression you need something that can pack an arbitrary length bit strings into a buffer that's being built even if it has a natural 8 bit alignment. Your one question in such an implementation is going to be whether you pack the bits from 7 to 0 or from 0 to 7 in each byte.