How to convert the decimal number "18.25" to binary? I've been confused by the decimal points .25.
Just like you divide this 18 by 2 repeatedly to form a decimal representation for it, you need to do the reverse to convert the decimal part of the number to binary. You need to multiply that decimal portion of the number by 2 repeatedly until it gives a standalone digit. The result(product) of the first multiplication will be the input to the second multiplication and this continues until we reach a stagnant steady integer value.
So, in your case, the 18.25's decimal part is 0.25.
Let's begin by multiplying it with 2.
0.25*2=0.5 // 0
0.5*2=1.0 // 1
Hunt finishes as we end up with the product coming as a standalone integer.
Also, the decimal to binary conversion of 18 is (10010)base 2. This you can easily calculate as you know it,mentioned in the question.
Hence, the decimal representation for 18.25 will be (10010.01)base 2---see,serially 01 in the order unlike the numbers where we traverse from bottom to top!
I hope it is clear.
with recursiveCTE(num) as (
select &EnterNum num from dual
union all
select trunc(num/2) from recursiveCTE
where trunc(num/2)> 0
),
ref as (SELECT num, mod(num, 2) bin_remainder from recursiveCTE)
select reverse(to_char(replace(wm_concat(bin_remainder), ','))) binary_num from ref;
Related
How do I represent integers numbers, for example, 23647 in two bytes, where one byte contains the last two digits (47) and the other contains the rest of the digits(236)?
There are several ways do to this.
One way is to try to use Binary Coded Decimal (BCD). This codes decimal digits, rather than the number as a whole into binary. The packed form puts two decimal digits into a byte. However, your example value 23647 has five decimal digits and will not fit into two bytes in BCD. This method will fit values up to 9999.
Another way is to put each of your two parts in binary and place each part into a byte. You can do integer division by 100 to get the upper part, so in Python you could use
upperbyte = 23647 // 100
Then the lower part can be gotten by the modulus operation:
lowerbyte = 23647 % 100
Python will directly convert the results into binary and store them that way. You can do all this in one step in Python and many other languages:
upperbyte, lowerbyte = divmod(23647, 100)
You are guaranteed that the lowerbyte value fits, but if the given value is too large the upperbyte value many not actually fit into a byte. All this assumes that the value is positive, since negative values would complicate things.
(This following answer was for a previous version of the question, which was to fit a floating-point number like 36.47 into two bytes, one byte for the integer part and another byte for the fractional part.)
One way to do that is to "shift" the number so you consider those two bytes to be a single integer.
Take your value (36.47), multiply it by 256 (the number of values that fit into one byte), round it to the nearest integer, convert that to binary. The bottom 8 bits of that value are the "decimal numbers" and the next 8 bits are the "integer value." If there are any other bits still remaining, your number was too large and there is an overflow condition.
This assumes you want to handle only non-negative values. Handling negatives complicates things somewhat. The final result is only an approximation to your starting value, but that is the best you can do.
Doing those calculations on 36.47 gives the binary integer
10010001111000
So the "decimal byte" is 01111000 and the "integer byte" is 100100 or 00100100 when filled out to 8 bits. This represents the float number 36.46875 exactly and your desired value 36.47 approximately.
How to represent 500.2 in binary number system. I want to know the conversion method. I know how to convert numbers without points but if point comes in any number I don't know how to convert it.
Quoting the conversion description from Modern Digital Electronics 4E
Decimal to Binary conversion :
Any decimal number can be converted into its equivalent binary number.
For integers, the conversion is obtained by continuous division by 2
and keeping track of the remainders, while for fractional parts, the
conversion is affected by continuous multiplication by 2 and keeping
track of the integers generated.
The conversion process in your case is illustrated below :-
500/2 = 250 Remainder = 0
250/2 = 125 Reaminder = 0
125/2 = 62 Remainder = 1
62/2 = 31 Remainder = 0
31/2 = 15 Remainder = 1
15/2 = 7 Remainder = 1
7/2 = 3 Remainder = 1
3/2 = 1 Remainder = 1
1/2 = 0 Remainder = 1
So, the order of evaluation is that topmost remainder will go to LSB, the bottom-most remainder would go to MSB.
Therefore, (500)2 = 111110100.
Now, talking about the fractional part, we would go as follows :-
// separate the integer generated(0 or 1) on the left hand side of the fraction/dot,
// and ensure only fractional part between 0 and 1 are allowed in the next step
0.2 * 2 = 0.4 , so, keep 0 in the bag
0.4 * 2 = 0.8 , so, keep 0 in the bag
0.8 * 2 = 1.6 , so, keep 1 in the bag, and next put 0.6 to the next step
0.6 * 2 = 1.2, so, keep 1 in the bag, and next put 0.2 to the next step
0.2 * 2 = 0.4, so, keep 0 in the bag...
// and so on as we see that it would continue(repeating) the same pattern.
As we find that the series would go on infinitely, we can consider only the precision upto certain decimal places.
So, if I assume that the required precision is 4 digits after the dot, then the answer would be the sequence in which the digits are being placed in the bag, i.e.,
(0.2)2 = 0.00110011...
= 0.0011....
= 0.0011.
Now, combinedly, (500.2)2 = 111110100.0011 .
Here is a good webpage about it. I don't know if it answers your question :
http://www.h-schmidt.net/FloatConverter/IEEE754.html
Edit
from that link
Usage: You can either convert a number by choosing its binary representation in the button-bar, the other fields will be updated immediately. Or you can enter a binary number, a hexnumber or the decimal representation into the corresponding textfield and press return to update the other fields. To make it easier to spot eventual rounding errors, the selected float number is displayed after conversion to double precision.
Special Values: You can enter the words "Infinity", "-Infinity" or "NaN" to get the corresponding special values for IEEE-754. Please note there are two kinds of zero: +0 and -0.
Conversion: The value of a IEEE-754 number is computed as:
sign * 2exponent * mantissa
The sign is stored in bit 32. The exponent can be computed from bits 24-31 by subtracting 127. The mantissa (also known as significand or fraction) is stored in bits 1-23. An invisible leading bit (i.e. it is not actually stored) with value 1.0 is placed in front, then bit 23 has a value of 1/2, bit 22 has value 1/4 etc. As a result, the mantissa has a value between 1.0 and 2. If the exponent reaches -127 (binary 00000000), the leading 1 is no longer used to enable gradual underflow.
Underflow: If the exponent has minimum value (all zero), special rules for denormalized values are followed. The exponent value is set to 2-126 while the "invisible" leading bit for the mantissa is no longer used. The range of the mantissa is now [0:1).
Note: The converter used to show denormalized exponents as 2-127 and a denormalized mantissa range [0:2). This is effectively identical to the values above, with a factor of two shifted between exponent and mantissa. However this confused people and was therefore changed (2015-09-26).
Rounding errors: Not every decimal number can be expressed exactly as a floating point number. This can be seen when entering "0.1" and examining its binary representation which is either slightly smaller or larger, depending on the last bit.
Other representations: The hex representation is just the integer value of the bitstring printed as hex. Don't confuse this with true hexadecimal floating point values in the style of 0xab.12ef.
For plsql data type NUMBER(x) is want to know the maximum number of digits after the decimal place it can hold (assuming i am using only 1 digit before decimal point) . Is there some rule by which this can be derived .
According to Oracle's documentation:
NUMBER
999...(38 9's) x10125 maximum value
-999...(38 9's) x10125 minimum value
Can be represented to full 38-digit precision (the mantissa).
Simply said, you have 38 significant (decimal) digits.
Given your case, if you use 1 digit before the decimal point, you still have 37 digits available at max just after the decimal point:
NUMBER(38,37)
This will cover the range:
-9.9999999999999999999999999999999999999
+9.9999999999999999999999999999999999999
With an ULP of:
0.0000000000000000000000000000000000001
This is better in term of precision than IEEE754 floating point numbers and you will have exact representation of decimal numbers.
As a side-note, few things to know:
NUMBER(x) is the same thing as NUMBER(x,0). That is a signed decimal integer.
PL/SQL will silently discard numbers after the decimal separator when doing an affectation to a number with a scale lower than the original. see this example:
declare
n1 number(12,1);
n2 number(11);
begin
n1 := 12345678901.2;
dbms_output.put_line(n1);
n2 := n1; -- loose precision here !!!
n1 := n2;
dbms_output.put_line(n1);
dbms_output.put_line(n2);
end;
Displaying 12345678901.2, and then 12345678901 and 12345678901
The CAST operator will behave exactly same manner:
select CAST(12345678901.2 AS NUMBER(11)) FROM DUAL;
resulting in 12345678901.
Iam dividing two numbers in R. The numerator is a big integer ( ranges in millions) divided by a 13.00001
It is taking 13.000001 as 13 and the output that comes is limited to only 1 decimal place.
I require the output to be uptil 2 decimal places which is not happening.
I tried round, format and as.numeric but it is fruitless
round is not giving anything (round(divison,1)
format(nsmall=2) makes it upto 2 decimal places but converts it into character
as.numeric reconverts it from character but the 2 decimal places are replaced by 1 decimal place
Is there any way that I can get 2 decimal places when I divide an integer with a number like 13.000001?
Be careful not to confuse output with internal precision:
x <- 13e7/13.000001
sprintf("%10.20f",x)
#[1] "9999999.23076928965747356415"
sprintf("%10.10f",x*13)
#[1] "129999990.0000007600"
sprintf("%10.10f",x*13.000001)
#[1] "129999999.9999999851"
Differences to the expected output are due to the limited floating point precision.
i've been asked to work on the following question with the following specification/ rules...
Numbers are held in 16 bits split from left to right as follows:
1 bit sign flag that should be set for negative numbers and otherwise clear.
7 bit exponent held in Excess 63
8 bit significand, normalised to 1.x with only the fractional part stored – as in IEEE 754
Giving your answers in hexadecimal, how would the number -18 be represented in this system?
the answer is got is: 11000011 00100000 (or C320 in hexadecimal)
using the following method:
-18 decimal is a negative number so we have the sign bit set to 1.
18 in binary would be 0010010. This we could note down as 10010. We know work on what’s on the right side of the decimal point but in this case we don’t have any decimal point or fractions so we note down 0000 0000 since there are no fractions. We now write down the binary of 18 and the remainder zeroes (which are not necessarily required) and separate them with a decimal point as shown below:
10010.00000000
We now normalise this into the form 1.x by moving the decimal point and placing it between the first and second number (counting the amount of times we move the decimal point until it reaches that area). The result now is 1.001000000000 x 2^4 and we also know that the decimal point has been moved 4 times which for now we will consider to be our exponent value. The floating point system we are using has 7 bit exponent and uses excess 63. The exponent is 4 in excess 63 which would equal to 63 + 4 = 67 and this in 7 bit binary is shown as 1000011.
The sign bit is: 1 (-ve)
Exponent is: 1000011
Significand is 00100…
The binary representation is: 11000011 00100000 (or C320 in hexadecimal)
please let me know if it's correct or if i've done it wrong and what changes could be applied. thank you guy :)
Since you seem to have been assigned a lot of questions of this type, it may be useful to write an automated answer checker to validate your work. I've put together a quick converter in Python:
def convert_from_system(x):
#retrieve the first eight bits, and add a ninth bit to the left. This bit is the 1 in "1.x".
significand = (x & 0b11111111) | 0b100000000
#retrieve the next seven bits
exponent = (x >> 8) & 0b1111111
#retrieve the final bit, and determine the sign
sign = -1 if x >> 15 else 1
#add the excess exponent
exponent = exponent - 63
#multiply the significand by 2^8 to turn it from 1.xxxxxxxx into 1xxxxxxxx, then divide by 2^exponent to get back the decimal value.
result = sign * (significand / float(2**(8-exponent)))
return result
for value in [0x4268, 0xC320]:
print "The decimal value of {} is {}".format(hex(value), convert_from_system(value))
Result:
The decimal value of 0x4268 is 11.25
The decimal value of 0xc320 is -18.0
This confirms that -18 does convert into 0xC320.