converting 0d1221 to ob0110

Go To Last Post
19 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I need it to convert Huffman codes to binary.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Please Read: Code-of-Conduct

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Subtract 1 from each digit in the number sequence.

Ross McKenzie, Melbourne Australia

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

https://godbolt.org/z/y_3Cst

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

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 ??

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Likewise!

 

surprise

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...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

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.

 

Yup, I have that part completed, just needs tested.  I packing from 7 - 0.  Easy enough.  Now I need to unpack the data from the Stream,  should be easy enough.

 

As to why I started with the code being 112122  is I knew how many bits where in contention.