Floating point to fixed point conversion - matlab

I am working on floating point to fixed point theory in Matlab. I just need to convert a negative decimal number into binary string but dec2bin command is not working. Kindly suggest me some solution.
please see the following code
freq=-7.2722e-005
u_frac=25
u_fi0=freq*2^u_frac
u_fi=round(u_fi0)
u_fi_b= dec2bin(u_fi0)

For a 32-bit signed integer, you have to add 2^32 to ever negative number:
dec2bin(u_fi0+2^32)
The result is:
11111111111111111111011001110111

Related

matlab floating number accuracy 2^(-45)

I have two pair of numbers (155.11 , 155.35) and (154.95 , 155.19), their differences are both 0.24. In matlab if I calculate
(155.11 - 155.35) - (154.95 - 155.19), the matlab will output 2.8422e-14,which is 2^(-45). I know this is an issue of machine resolution on floating number representation, but was curious on the detail, why it is this value? what is special on 45?
eps(155.11) is 2.8422e-14. The rounding already happens in the original numbers you enter.

converting 64 bits binary 1D vector into corresponding floating and signed decimal number

Please let me know how to achieve this as I tried a lot but didn't get the desired result for vector, u=[0;1;0;0;1;1;0;0;0;0;1;1;0;1;1;1;1;0;0;0;1;0;0;1;0;1;0;0;0;0;0;1;0;1;1;0;0;0;0;0;0;0;0;0;1;1;0;1;0;1;0;1;1;0;1;1;1;1;0;0;0;0;0;0];
desired output=-108.209
Regards
Nitin
First off, I think your expectation for a correct answer is off. The first bit in a double is the sign. So if you're expecting a negative number, the first bit should be 1. Even if you had your bits backward, it's still a leading 0. There are all sorts of binary to float calculators if you search for them. Here's an example:
http://www.binaryconvert.com/result_double.html?hexadecimal=4C378941600D5BC0
To answer your question for how to do this in Matlab, Matlab's built in function for converting from binary is bin2dec. However, it's expecting a char array as an input, so you'll need to convert to char with num2str. The other trick here is that bin2dec only supports up to 53 bits. So you'll need to break it into two 32 bit numbers. The last piece of the puzzle is to use typecast to convert your pair of 32bit integers into a double. Put it all together, and it looks like this:
bits = [0;1;0;0;1;1;0;0;0;0;1;1;0;1;1;1;1;0;0;0;1;0;0;1;0;1;0;0;0;0;0;1;0;1;1;0;0;0;0;0;0;0;0;0;1;1;0;1;0;1;0;1;1;0;1;1;1;1;0;0;0;0;0;0];
int1 = uint32(bin2dec(num2str(bits(1:32)')));
int2 = uint32(bin2dec(num2str(bits(33:64)')));
double_final = typecast([int2 int1],'double')

Why this happens in floating point conversion?

I noticed that some floating points converted differently. This question helps me about floating points however still don't know why this happens? I added two screenshots from debug mode about the sample code. Example values : 7.37 and 9.37. Encountered it in swift and surely swift uses IEEE 754 floating point standard Pls explain how this happens? How conversion ended differently ?
if let text = textField.text {
if let number = formatter.number(from: text) {
return Double(number)
}
return nil
}
Double floating point numbers are stored in base-2, and cannot represent all decimals exactly.
In this case, 7.37 and 9.37 are rounded to the nearest floating point numbers which are 7.37000000000000010658141036401502788066864013671875 and 9.3699999999999992184029906638897955417633056640625, respectively.
Of course, such decimal representations are too unwieldy for general use, so programming languages typically print shorter approximate decimal representations. Two popular choices are
The shortest string that will be correctly rounded to the original number (which in this case are 7.37 and 9.37, respectively).
Rounded 17 significant digits, which is guaranteed to give the correct value when converting back to binary.
These appear to correspond to the 2 debug output values that you are seeing.

How to stop matlab truncating long numbers

These two long numbers are the same except for the last digit.
test = [];
test(1) = 33777100285870080;
test(2) = 33777100285870082;
but the last digit is lost when the numbers are put in the array:
unique(test)
ans = 3.3777e+16
How can I prevent this? The numbers are ID codes and losing the last digit is screwing everything up.
Matlab uses 64-bit floating point representation by default for numbers. Those have a base-10 16-digit precision (more or less) and your numbers seem to exceed that.
Use something like uint64 to store your numbers:
> test = [uint64(33777100285870080); uint64(33777100285870082)];
> disp(test(1));
33777100285870080
> disp(test(2));
33777100285870082
This is really a rounding error, not a display error. To get the correct strings for output purposes, use int2str, because, again, num2str uses a 64-bit floating point representation, and that has rounding errors in this case.
To add more explanation to #rubenvb's solution, your values are greater than flintmax for IEEE 754 double precision floating-point, i.e, greater than 2^53. After this point not all integers can be exactly represented as doubles. See also this related question.

Read half precision float (float16 IEEE 754r) binary data in matlab

you have been a great help last time, i hope you can give me some advise this time, too.
I read a binary file into matlab with bit16 (format = bitn) and i get a string of ones and zeros.
bin = '1,00011,1111111111' (16 bits: 1. sign, 2-6. exponent, 7-16. mantissa)
According to ftp://www.fox-toolkit.org/pub/fasthalffloatconversion.pdf it can be converted like
out = (-1)^bin(1) * 2^(bin(2:6)-15) * 1.bin(7:16) [are exponent and mantissa still binary?]
Can someone help me out and tell me how to deal with the 'eeeee' and '1.mmmmmmmmmm' as mentioned in the pdf, please.
Thanks a lot!
Michael
This Guy made a wonderful C++ header file to deal with float16 - half precision float. Awesome!
Michael