Three-digit Complement

Jiang Yongjiang Altera Cup National Graduate Electronic Design Competition has a simple question of "representing-37 as a three-digit complement code. The instructor with a score raised an objection to the answer as soon as he came up, believing that 1122 (3) The result is incorrect, because "except the highest sign bit", 122(3) = 1 × 32 + 2 × 31 + 2 × 30 = 17. This shows that there are problems in our long-term theoretical teaching of digital circuit design. There is a loophole in the phrase "representing-37 as a triplicate complement", that is, it does not propose "using a few bits". Otherwise, there will be multiple expressions. For example, 1122(3), 21122(3), 221122(3), 2221122(3 ),......, The values are-37. The four-digit three-digit unsigned integer is 0000.(3 )~ 2222(3) The 81 numbers. If they are used to represent signed integers, the range is-1111.(3 )~ + 1111(3)-40 to decimal ~ + 40. Judging whether the four-digit three-digit complement code indicates the positive and negative values of the value, you cannot see whether the highest digit is "0" or "1", but whether the unsigned integer is greater than 1111(3), yes, it is a negative number. Therefore, the minimum bitwise tridecimal Number of 37 is 1101.(3) Based on the "inverse plus one" (why), the 4-digit tri-hexadecimal representation of-37 is 1122.(3 ).



I am mainly used to write high-precision operations of arbitrary hexadecimal numbers. I feel that it is not very useful, I just don't need to write a single high-precision subtraction-minus the complement code with a number equal to the corresponding negative number, which can solve a lot of problems, however, there are already many templates for high-precision algorithms available on the Internet. It is just interesting to write this arbitrary code-filling question here, and it is also one of the few original jobs.
As for the reason for thinking about the complement of any hexadecimal number, I also want to read a book some time ago and give a piece of pseudo code about binary addition, which is very short, instead of thinking of the code of the previously written high-precision decimal algorithm, I suddenly found that this can be extended to any expected hexadecimal system. This is a piece of classic code. Write the pseudo code here.
The two numerics are base, which are: (anan-1... a2a1) base, (bnbn-1... b2b1) base, and the numbers are saved to S:

C branch 0
For I want 1 to n
TEMP environment [(AI + Bi + C)/base]
Si healthcare ai + Bi + C-Temp * base
C producer temp

Then I saw another algorithm about binary multiplication, which is a grouping algorithm that splits two n-bit multiplier values into N/2 bits and low N/2 bits, respectively, we know that for the base number of the base number, if we shift the number to the left and multiply the T bit by Baset, we can introduce the following formula:
If a = (anan-1... a2a1) base, B = (bnbn-1... b2b1) base, a1 = (anan-1... an/2 + 1) base, a0 = (AN/2an/2-1... a1) base, b1 = (bnbn-1... BN/2 + 1) base, b0 = (Bn/2Bn/2-1... b1) Base
Then a * B = (basen/2 * A1 + a0) * (basen/2 * B1 + B0) = a1b1 * basen + (A1-B1) (B0-A0) + a1b1 + a0b0) * basen/2 + a0b0.
In this way, recursive computation is required to call the cubic multiplication function in the program. If the time complexity of this algorithm is T (N), then when n = 1, t (N) = O (1); otherwise, T (n) = 3 T (n/2) + O (n ). The time complexity of this recursive formula is T (n) = O (nlog3) = O (n1.585 ). It is faster than the ordinary high-precision multiplication algorithm's O (n2.
Because I saw the two algorithms above, I really wanted to write a high-precision Algorithm in any hexadecimal mode. During the writing process, there were a lot of troublesome problems, such as adding positive numbers to negative numbers or something, some judgment is required, which is not consistent with the simplified code I have imagined. I think the code will be much simpler if any hexadecimal number can be expressed by a complement code. However, at that time, his mind was a little difficult, and he did not think about it. Later, he accidentally mentioned it with a friend, and he was also very interested in it, so the two of us spent two or three nights studying the arbitrary hexadecimal CAPTCHA complement problem. The following describes the results. Because the level is really limited, it is inevitable that there is something wrong. I hope you can correct it.
We can consider the source of any hexadecimal number complement. We know that if a clock pointer is at and you want to place it at three points, you can dial three cells forward and nine cells backward. It can be considered that the clock is a 12-hour representation, and the "complement" of-3 can be said to be 9. Then we will promote it to the familiar decimal system. If two digits are added together, we can think of it as a dial with ten grids. If it is two digits, you can think of it as a dial with one hundred grids. In this way, if it is a single digit, its complement code can be expressed as 10 minus this number, and the two digits can be expressed as 100 minus this number, then for the decimal number, the complement of any negative number is to subtract 9 from each other and add another one. Now, let's think about the bitwise complement of binary and add another one. If we promote this rule to base-based, the complement code of a negative number is to subtract it from base by bit and then add another one.
In this case, a problem occurs. For example, in decimal format, the complement code of-3 is 7, but the complement Code of 7 is also 7. Given a complement Code of 7, we don't know whether the number is-3 or 7. Here we can refer to the binary complement coding method. We will add the symbol bit before. For the base hexadecimal number, if the negative sign bit is base-1, if the positive sign bit is 0. In this way, you can get a complement of the number by taking the inverse one of the bits.
Let's use the familiar decimal number as an example. For example, if we want to calculate 9-12 and use three units of space to store the number, the 9 complement code is, -The 2's complement code is 988,9-12. The complement code is calculated as 988 + 1997 = 993, where 1 overflows and the result is. The bitwise inversion result is-3, it is consistent with the correct result.
Let's take another example. We can see from this example that it is more elegant to take a few valid buckets. Let's take a look at-99-99. If we take three digits, we can use the complement code to calculate the value 901 + 901 = 1802. Then the result overflow is incorrect. If we use four digits, if the result is 9901 + 9901 = 9802, 198 is after overflow, then the original number is-, which is the correct result.
We can easily see that for addition, the larger the number of digits, the better, but there is too much space to waste. We can know that the two numbers are added, and the result of the addition is at most one bit larger than any of them, plus a signed bit, so the numbers of the two N bits are added, you only need to use N + 2 units of storage space.
Multiplication and addition are similar, but the valid bits are different. For multiplication, we can know that the number of bits in the result is no larger than the number of bits in two bits, so if the two numbers are N1 and N2, take N1 + N2 + 2.
For example, calculate-99 ×-99, take 6 Valid bits, use the complement code to calculate 999901 × 999901 = 999802009801, And take 6 Valid bits for 009801, the original number is 9801. It is consistent with the correct result.
The following briefly summarizes some rules for any hexadecimal number complement code:
For any base hexadecimal number,
(1) Complement: the positive complement is itself, the negative complement is bitwise using base subtraction, And the last plus one. If the original number has n digits, the number of valid digits of the complement code is n + 1 (where n + 1 is the symbol bit ).
(2) Valid bits: If the complement code of a number is originally x bits, if you want to take the valid bits y (> X), if this number is a positive number, then fill in 0 between x + 1 and Y, otherwise fill in base-1.
(3) addition: the number of A digits and the number of B (<= A) digits are added, and the valid bit is a + 2.
(4) multiplication: A single A-digit and B-digit are added, and the valid bits are A + B + 2.
In this way, we have summarized the simplest Code complement rules for any number in hexadecimal notation. There will be some details not mentioned, and due to the limited level, there will inevitably be many errors and deficiencies, I hope you can correct them more. In future articles, I may offer high-precision code that is implemented by code completion.