Decimal <--> Two's Complement <--> Hex conversion - hex

I'm wondering if I get a question like:
"Convert a decimal number to two's complement, then give your answer in Hex".
Is the path below, how one would do it?
Decimal number: -23
23 = 00010111 = in hex 17 = -17
-23 = 11101001 = in hex E9
So to convert it to Hex would the answer be -17 or E9?
Thanks


The -17 has no relevance here, since according to your task, you have to return the two's complement as HEX and that is E9.
Your conversion path in general looks correct to me.
DEC to BIN without the sign:
23 → 0001 0111
Negate the BIN string:
0001 0111 → 1110 1000
Add 1 to the negated BIN result:
1110 1000 + 0000 0001 → 1110 1001
Verify the correct two's complement calculation:
-128 + 64 + 32 + 8 + 1 = -23 → correct
Convert final BIN string to HEX:
1110 1001 → 0xE9

Related

TCPDF - Problem with Alphanumerical characters (wrong size)

I have a size problem when using TCPDF to generate QR code with only ALPHANUMERICAL characters. My objective: generate the longest URL (with a random part), but keeping the QR code at its lowest size, i.e. 21x21 modules (version1).
Documentation (QRcode.com) reports that using only alphanumerical characters set (thonky.com), URL can be 25 characters long with ERC set to L.
Using write2DBarCode with this 25 Alphanumerical URL leads to version1 (21x21mod) QR as expected
$pdf->write2DBarcode('HTTP://SITE-COM/123456789', 'QRCODE,L', 20, 20, 40, 40, $style, 'N');
but changing to this other URL, with also 25 Alphanumerical, I get a version 2 (25x25mod) QR code, whereas a version 1 could be done (Tested on Nayuki)
$pdf->write2DBarcode('HTTP://TXT-CH/AYAWEQYAF4A', 'QRCODE,L', 20, 70, 40, 40, $style, 'N');
I join the TCPDF Outputs of the 2 QR codes given as examples TCPDF Outputs
Thank you in advance for your help on this wonderful TCPDF library.

Short answer: The TCPDF software that you are using is suboptimal. It is generating a full 4-bit terminator even when a shorter one suffices. Please contact the software's authors to fix the problem. You can link them to this thread.
So I cropped your image into two QR Code images, and submitted them to ZXing Decoder Online and KaarPoSoft QR Decode with debug output.
ZXing, first barcode:
Decode Succeeded
Raw text HTTP://SITE-COM/123456789
Raw bytes 20 83 1a a6 5f 9f d5 b4 75 3e 8d 20 48 81 23 db 91 8a 80
Barcode format QR_CODE
Parsed Result Type URI
Parsed Result HTTP://SITE-COM/123456789
ZXing, second barcode:
Decode Succeeded
Raw text HTTP://TXT-CH/AYAWEQYAF4A
Raw bytes 20 cb 1a a6 5f 9f d6 5e ae 82 ca 0f 21 e2 52 18 11 53 94 00 ec 11 ec 11 ec 11 ec 11 ec 11 ec 11 ec 11
Barcode format QR_CODE
Parsed Result Type URI
Parsed Result HTTP://TXT-CH/AYAWEQYAF4A
KaarPoSoft, first barcode:
Debug output
skew_limit=7.21875
skew=0
left=31 right=427 top=27 bottom=423
size=397
matchVersion version=1 finder0=64 finder1=64 finder2=64
matchVersion version=1 timing0=1 timing1=1 alignment=1
matchVersion version=1 format_NW =14 0 format_NESW =14 1 format = 14 ecl = 1 mask = 6
matchVersion version=1 grades(F(V)TAF): 4444->4
findModuleSize matchVersion version=1 grade=4
findModuleSize version=1 grade=4 error_correction_level=1 mask=6
getCodewords mask=6 length=26
getCodewords = 32,131,26,166,95,159,213,180,117,62,141,32,72,129,35,219,145,138,128,62,191,105,157,147,176,164
setBlocks n_blocks_first=1 n_blocks_second=0 n_blocks=1 n_block_words_first=19 n_block_words_second=0 n_block_ec_words=7 total=26
setBlocks block 0 (26): 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25
RS calculateSyndroms: No errors
correctErrors in = 32,131,26,166,95,159,213,180,117,62,141,32,72,129,35,219,145,138,128,62,191,105,157,147,176,164
correctErrors out = 32,131,26,166,95,159,213,180,117,62,141,32,72,129,35,219,145,138,128
error_grade=4
extractData bytes in (19) = 32,131,26,166,95,159,213,180,117,62,141,32,72,129,35,219,145,138,128
extractData mode = 2
extractAlphanum charcount = 16
extractData mode = 1
extractNumeric charcount = 9
extractData mode = 0
extractData data(25) = 72,84,84,80,58,47,47,83,73,84,69,45,67,79,77,47,49,50,51,52,53,54,55,56,57
KaarPoSoft, second barcode:
Debug output
skew_limit=7.015625
skew=1
left=21 right=417 top=30 bottom=425
size=396.5
findModuleSize matchVersion version=1 grade=0
matchVersion version=2 finder0=64 finder1=64 finder2=64
matchVersion version=2 timing0=1 timing1=1 alignment=1
matchVersion version=2 format_NW =14 0 format_NESW =14 1 format = 14 ecl = 1 mask = 6
matchVersion version=2 grades(F(V)TAF): 4444->4
findModuleSize matchVersion version=2 grade=4
findModuleSize version=2 grade=4 error_correction_level=1 mask=6
getCodewords mask=6 length=44
getCodewords = 32,203,26,166,95,159,214,94,174,130,202,15,33,226,82,24,17,83,148,0,236,17,236,17,236,17,236,17,236,17,236,17,236,17,87,194,99,197,7,184,131,204,163,52
setBlocks n_blocks_first=1 n_blocks_second=0 n_blocks=1 n_block_words_first=34 n_block_words_second=0 n_block_ec_words=10 total=44
setBlocks block 0 (44): 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43
RS calculateSyndroms: No errors
correctErrors in = 32,203,26,166,95,159,214,94,174,130,202,15,33,226,82,24,17,83,148,0,236,17,236,17,236,17,236,17,236,17,236,17,236,17,87,194,99,197,7,184,131,204,163,52
correctErrors out = 32,203,26,166,95,159,214,94,174,130,202,15,33,226,82,24,17,83,148,0,236,17,236,17,236,17,236,17,236,17,236,17,236,17
error_grade=4
extractData bytes in (34) = 32,203,26,166,95,159,214,94,174,130,202,15,33,226,82,24,17,83,148,0,236,17,236,17,236,17,236,17,236,17,236,17,236,17
extractData mode = 2
extractAlphanum charcount = 25
extractData mode = 0
extractData data(25) = 72,84,84,80,58,47,47,84,88,84,45,67,72,47,65,89,65,87,69,81,89,65,70,52,65
Both QR Codes appear to have no problems regarding error correction or format violations.
From the KaarPoSoft output, we can see the segments in the QR Codes.
The first barcode has two segments:
Alphanumeric mode, count = 16, text = "HTTP://SITE-COM/". Segment bit length = 4 (mode) + 9 (count) + 88 (data) = 101 bits.
Numeric mode, count = 9, text = "123456789". Segment bit length = 4 (mode) + 10 (count) + 30 (data) = 44 bits.
The second barcode has one segment:
Alphanumeric mode, count = 25, text = "HTTP://TXT-CH/AYAWEQYAF4A". Segment bit length = 4 (mode) + 9 (count) + 138 (data) = 151 bits.
Now, a QR Code at version 1 with low error correction level has capacity for 19 data codeword bytes, or 152 bits. The first barcode uses 101 + 44 = 145 bits = 19 bytes (rounded up), so it fits. The second barcode uses 151 bits = 19 bytes (rounded up), so it fits. So in theory, both lists of segments of text data should fit in version 1 low ECC.
According to the QR spec, after the list of segments ends, these bits are appended:
(TERM) Up to four "0" bits (but less if the data capacity is reached) for the terminator pseudo-mode.
(BITPAD) Zero to seven "0" bits to fill up the last partial byte.
(BYTEPAD) Alternating bytes of 0xEC and 0x11 until the data capacity is reached.
Let's dissect what actually happened. Convert the ZXing hexadecimal byte output to binary, and annotate the fields.
First barcode:
20 83 1a a6 5f 9f d5 b4 75 3e 8d 20 48 81 23 db 91 8a 80
0010 000010000 [88 bits] 0001 0000001001 [30 bits] 0000 000 (Total length = 152 bits)
^Mode ^Count ^Data ^Mode ^Count ^Data ^TERM ^BITPAD
Second barcode:
20 cb 1a a6 5f 9f d6 5e ae 82 ca 0f 21 e2 52 18 11 53 94 00 ec 11 ec 11 ec 11 ec 11 ec 11 ec 11 ec 11
0010 000011001 [138 bits] | 0000 00000 11101100 00010001 [...] (Total length = 272 bits)
^Mode ^Count ^Data | ^TERM ^BITPAD ^BYTEPAD
Note that in the second barcode, at the position | just before the TERMinator, there are 151 bits on the left side. The terminator is normally four "0" bits, but is allowed to be shortened if the capacity (of 152 bits) is reached. So the optimal terminator is a single bit of "0", and then there must be no bit padding and no byte padding.

15 Hex in Binary form, explanation required?

I really really really can't understand how 15hex converted in Binary form gives me 10101bin.
That should be easy but I can't get it 😰

0x15 == 1*16 + 5*1 == 21
21 == 1*16 + 0*8 + 1*4 + + 0*2 + 1*1 == 10101 (binary)
What's not to love?

Well it's simple. In decimal base, number 15 means
10 + 5, because the number 1 means 1 * 10, and number 5 means 5 * 1.
And in hex, number 15 means:
1 * 16 + 5 * 1, meaning its 21. 21 in binary is 10101.

How to convert hex to binary
Convert each hex digit to 4 binary digits according to this table:
Hex Binary
0 0000
1 0001
2 0010
3 0011
4 0100
5 0101
6 0110
7 0111
8 1000
9 1001
A 1010
B 1011
C 1100
D 1101
E 1110
F 1111
Example #1
Convert (4E)16 to binary:
(4)16 = (0100)2
(E)16 = (1110)2
So
(4E)16 = (01001110)2
Example #2
Convert(4A01)16 to binary:
(4)16 = (0100)2
(A)16 = (1010)2
(0)16 = (0000)2
(1)16 = (0001)2
So
(4A01)16 = (0100101000000001)2

How do I convert a hexadecimal number in IEEE 754 double precision (64bit) format to a decimal number?

My task is to convert a hexadecimal number in double precision format (IEEE 754) on a paper.
I've converted a hexadecimal number: 0x40790A0000000000 to a binary 64bit format so far and now I have:
0 10000000111 1001000010100000000000000000000000000000000000000000
For the next step I am not totally sure what to do. I have to convert it into a decimal number and I've tried out several ways, but never got the right result.
Hope you can help me and thank you.

Going from https://en.wikipedia.org/wiki/Double-precision_floating-point_format,
4 0 7 9 0 A 0 0 0 0 0 0 0 0 0 0
0100 0000 0111 1001 0000 1010 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0 - Sign bit (this is a positive number)
100 0000 0111 - Exponent
1001 0000 1010 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 - Fraction
The exponent's value is 1031. Because it's nonzero the fractional part is given by the expression 1 + sum from i = 1 to 52 bit_(52-i) * 2^(-i).
The fraction's value is therefore 1 + 1/2 + 0/4 + 0/8 + 1/16 + ... ~= 1.56
From there you should be able to figure the rest out.
(Not solving this completely because this looks like homework.)

how to find the remainder of division

Q=A/B , Q is a real number expressed as a pair of 8 bits:
most significant 8 bits for the integer part
least significant 8 bits for the fractional part
the number is unsigned
for example:
0 0 1 0 1 1 0 1 . 0 1 0 1 0 0 0 0
Can you find the remainder of division if you know B, on a paper? how?
I'll give an example:
2/172 :
0000 0010 . 0000 0000 /
1010 1100 . 0000 0000
=0000 0000 . 0001 0010
0000 0000 . 0001 0010 *
1010 1100 . 0000 0000
=0000 0000 . 1100 0001 (should be 2, or at least something greater than 1.5)

There are two algorithms: restoring and non-restoring. This is very well described in Division Algorithms and Hardware Implementations by Sherif Galal and Dung Pham. And here is about implementation in VHDL.

Why does 0xff & abcd truncate half of the abcd?

I can understand binary operation 11 & x, for example if x = 1011, the operation will take out 10 from x and left x to be 11. However, when it comes to hexadecimal, I am very confused. What is the math and reasoning behind the similar effect of 0xff & x? I can only understand this if I convert them all to binary.

0xFF & 0xABCD = 0xCD ... why?
Because:
A = 1010
B = 1011
C = 1100
D = 1101
F = 1111
So the 0xFF = 0x00FF = 0000 0000 1111 1111
The 0xABCD = 1010 1011 1100 1101
-------------------
0xFF & 0xABCD = 0000 0000 1100 1101
As with most things, once you work with hex for a while, you'll learn some tricks for remembering the values.

Resources