Since I knew how to manually convert hexadecimal to decimal using this method.
Read from right to left, the last digit multiplied by the constant value 16 and plus the first digit.
For example:
12h = 2 + (1 * 16) = 18
99h = 9 + (9 * 16) = 153
How do I convert back into hex from decimal?
As you can see in the picture above. You need to draw a table in your brain
Lets take 456 as example.
If we divide 456 by 16 . Remainder = 8 & Quotient = 28
We further divide 28 by 16 and get remainder = 12 & quotient = 1
Now further dividing 1 by 16 results in remainder = 1 and quotient = 0
So we stop.
Now we take the remainders, bottom up.
1 , 12 , 8
Converting 12 in hex notation gives C.
So the answer is 1C8
To convert from decimal to hex you must know the powers of 16. 16^1 is obviously 16; 16^2 is 256; 16^3 is 4096; 16^4 is 65536; etc.
For each power of 16, divide the number by that power to get one hex digit. Then take the remainder and divide by the next lower power of 16.
This is enough of a hassle that it's easiest to let a calculator do it, or use a scripting language such as Python.
Related
I am learning Solidity by following various tutorials online. One of these tutorials is Cryptozombies. In this tutorial we create a zombie that has "dna" (a number). These numbers must be only 16 digits long to work with the code. We do this by defining
uint dnaDigits = 16;
uint dnaModulus = 10 ** dnaDigits;
At some point in the lesson, we define a function that generates "random" dna by passing a string to the keccak256 hash function.
function _generateRandomDna(string memory _str) private view returns (uint) {
uint rand = uint(keccak256(abi.encodePacked(_str)));
return rand % dnaModulus;
}
I am trying to figure out how the output of keccak256 % 10^16 is always a 16 digit integer. I guess part of the problem is that I don't exactly understand what keccak256 outputs. What I (think) I know is that it outputs a 256 bit number. I bit is either 0 or 1, so there are 2^256 possible outputs from this function?
If you need more information please let me know. I think included everything relevant from the code.
Whatever keccak256(abi.encodePacked(_str)) returns, it converted into uint because of the casting uint(...).
uint rand = uint(keccak256(abi.encodePacked(_str)));
When it's an uint then the simple math, because it's modulus.
xxxxx % 100 always < 100
I see now that this code is mean to produce a number that has no more than 16 digits, not exactly 16 digits.
Take x % 10^16
If x < 10^16, then then the remainder is x, and x is by definition less than 10^16, which is the smallest possible number with 17 digits I.e. every number less than 10^16 has 16 or fewer digits.
If x = 10^16, then remainder is 0 which has fewer than 16 digits.
If x > 10^16, then either 10^16 goes into x fully or not. If it does fully, remainder is zero which has less than 16 digits, if it goes in partially, then remainder is only a part of 10^16 which will always have 16 or fewer digits.
A bit string is a string over the alphabet {0, 1}. A palindrome is a string whose reversal is
identical to the string. How many bit strings of length 15 are palindromes that don’t start with
111?
starts with 111 must ends with 111 so there're 9 bits left.
The center bit can be either 0 or 1. For each case, there are 4 bits to the left which can have 16 possible values, and the right 4 bits must match the left 4 bits.
So all together 2 * 16 = 32.
Well, sorry it should be "don't start with 111". Then it should be 32 * 7 = 224 possible values.
I would just like to confirm the following answer.
7037108.
8 does not form part of the number. Converting this to hexadecimal I get the answer ABCDE. Is this correct? If so what is the purpose of the subscript / base 8 which is written slightly below the number 703710.
A very simple way of converting octal to hex is through binary: octal digits correspond to three binary digits, while hex digits correspond to four. Convert the number to binary, regroup by four-bit nibbles, and then convert to hex.
The number converted to binary looks like this:
111 000 011 111 001 000
7 0 3 7 1 0
Regroup by nibbles and add leading zeros for conversion to hex:
0011 1000 0111 1100 1000
Now you can easily convert the number using a lookup table.
The subscript indicates what base the number is already written in, in this case 8, so it's octal.
So 7037108 is saying that the number is 7 * 8^5 + 0 * 8^4 + 3 * 8^3 + 7 * 8^2 + 1 * 8^1 + 0 * 8^0, or 231368 in base 10.
IOW, 7037108 = 23136810 = 387C816.
ABCDE (by which you mean ABCDE16, or 0xABCDE), would be the right answer if the original number were written in base 10, because 70371010 = ABCDE16.
I may formulated the question a bit wrong. I need to calculate the IPv4 header checksum in hexadecimal with paper and pen. At this link http://en.wikipedia.org/wiki/IPv4_header_checksum
on the last example they do it.
I have a bit of problem understanding how they count directly in hexadecimal. When doing it on paper what if I get a number over 15 for example 48 what reminder will I use and what will I write down?
Anyone that can explain how to handle this?
Thank you and sorry for formulating the question wrong but I have changed it now:)
See http://www.youtube.com/watch?v=UGK8VyV1gLE which describes the process very well.
Counting in HEX (base 16) is just like counting in decimal (base 10) except that you only start carrying remainders when you count past F.
So in your example from a comment, it's just like counting in decimal with no remainders:
15
24
---
39
A simple true HEX addition is:
11
F
---
20
1 + F = 10 = 1 remainder + 1 = 20
15 over 48 is simple too:
15
48
---
5D
8 + 5 = D no remainder, 1 + 4 = 5 no remainder
Hexadecimal is just a representation of numbers. In order to have the computer helping you with the addition you will have to convert the hexadecimal represented numbers to a number itself then do the addition and then convert it back. This is not a conversion to binary as binary is also only a different representation.
If you do not want the conversion from hexadecimal you will have to explain why you do not want to have this conversion.
I suppose this may sound like a dumb answer, but it's the best I can give with the way you wrote the question.
Addition in hex works exactly the same as in decimal, except with 16 instead of 10 digits. So in effect, what you're asking is how to do addition in general (including in decimal.) In dec, 9 + 1 = 10. In hex, F + 1 = 10. Obviously, the same rules of addition apply in both.
I know that you can split a power-of-two number in half like so:
halfintR = some32bitint & 0xFFFF
halfintL = some32bitint >> 16
can you do the same thing for an integer which is bounded by a non-power of two space?
(say that you want your range to be limited to the set of integers that will fit into 4 digit base 52 space unsigned)
You could use the following
rightDigits = number % 2704 // 52 squared
leftDigits = number / 2704
Well, of course. & 0xffff is the same as % 0x10000 and >> 16 is the same as / 0x10000. It is just that division by a power-of-two is more efficient when done with bit operations like shifting and masking. Division works with any number (within range of representation).
Once you realize that the & and >> are used for doing modulo und division calculation respectively, you can write what you want as:
lower = some4DigitsNumberBase52 % (52 * 52)
upper = some4DigitaNumberBase52 / (52 * 52)
This is the basis for doing base calculation. You can also derive the solution from the algorithm that displays a number in a specific base: how do you come up with the rightmost two digits and the 2 leftmost digits.