if dec2bin converts decimal to binary. and hex2dec converts hexadecimal to decimal. then how come bin2gray converts DECIMAL to gray?
MATLAB: Bin2gray function’s input is decimal.
barneyberbin2grayCommunications Toolboxsersmall furry creatures
Related Solutions
First you should convert the values to binary. You can do that with num2hex() to get hex that can be converted. Or you can use typecast() to reform the number into one of the unsigned integer data types.
Once you have the number in an unsigned integer data type, you can use bitget() or dec2bin() or de2bi() to convert the number into a binary form, from which you can extract individual groups of bits.
As a practical matter, I would point out that if you use dec2bin() on a uint64() then the number will be converted to double precision before it is converted to binary, and that is going to lose about 13 bits of value in the process (because uint64 are 64 bits and double precision can represent 53 bits.) I would therefore suggest that if you are planning to use dec2bin() that you do not typecast() to uint64 -- typecast to either uint8() or uint32() instead.
But personally I would probably typecast() to uint64, mod() to get the mantissa, bitshift() to remove the mantissa, mod() to get the exponent, bitshift() to get the sign...
You need to see the Fixed Point Toolbox.
You need to see it because it requires you to make explicit numerous assumptions about your arithmetic.
For example, since you used 1010 and 1100 and not (say) 00001010 and 00001100, then we don't know whether you simply used "leading 0 suppression" or if you mean to restrict your arithmetic to 4 digits. If you mean to restrict your arithmetic to 4 digits, then you need to define whether upon overflow (such as you get here) you want the overflowing bits to be discarded or you want to "saturate" to the highest possible representable value 1111 . Your addition is thus answerable by a minimum of 3 different values: 10110, 0110, and 1111.
But then there is the difficulty that when you use binary, the '+' operator often means "or", which would give you the additional possible answer 1110.
More generally, are the values to be added 52 bits long or less? If so then their sum is exactly representable in a double precision number for fast calculations. But as soon as you go to 53 bits, the sum might need 54 bits: sums that occupy 54 through 64 bits can only be done directly in R2010b or later, unless through the Fixed Point Toolbox.
Best Answer