ieee-754

I am porting some code from Matlab to C++. In Matlab format long D = 0.689655172413793 (this is 1.0 / 1.45) E = 2600 / D // I get E = 3.770000000000e+03 In C++ double D = 0.68965517241379315; //(this is 1.0 / 1.45) double E = 2600 / D; //I get E = 3769.9999999999995 It is a problem for me because in both cases I have to do rounding down to 0 (Matlab's fix), and in the first case (Matlab) is becomes 3770, whereas in the second case (C++) it becomes 3769. I realise that it is because of the two additional least significant digits "15" in the C++ case. Given that Matlab seems to only store up to

I've heard that javascript Numbers are IEEE 754 floating points, which explains why > 0.3 - 0.2 0.09999999999999998 but I don't understand > 0.1 0.1 I thought 0.1 couldn't be accurately stored as a base 2 floating point, but it prints right back out, like it's been 0.1 all along. What gives? Is the interpreter doing some rounding before it prints? It's not helping me that there are at least 2 versions of IEEE 754: 1984 edition and 2008 . It sounds like the latter added full support for decimal arithmetic . Doesn't seem like we have that. JavaScript uses IEEE-754 double-precision numbers (

The documentation for java.lang.Double.NaN says that it is A constant holding a Not-a-Number (NaN) value of type double . It is equivalent to the value returned by Double.longBitsToDouble(0x7ff8000000000000L) . This seems to imply there are others. If so, how do I get hold of them, and can this be done portably? To be clear, I would like to find the double values x such that Double.doubleToRawLongBits(x) != Double.doubleToRawLongBits(Double.NaN) and Double.isNaN(x) are both true. You need doubleToRawLongBits rather than doubleToLongBits . doubleToRawLongBits extracts the actual binary

I know that IEEE 754 defines NaNs to have the following bitwise representation: The sign bit can be either 0 or 1 The exponent field contains all 1 bits Some bits of the mantissa are used to specify whether it's a quiet NaN or signalling NaN The mantissa cannot be all 0 bits because that bit pattern is reserved for representing infinity The remaining bits of the mantissa form a payload The payload is propagated (as is the NaN as a whole) to the result of a floating point calculation when the input of the calculation is NaN, though I have no knowledge of the details of this propagation or

How can I change the 32 bit hex-value to a floating point value according to the IEEE 754? EDIT: ... data = fread(fid,1,'float32'); disp(data); ... I get this answer: 4.2950e+009 1.6274e+009 ... But how do I get 32 bit floating point (IEEE 754) numbers? Based on one of your comments it appears that your hexadecimal values are stored as strings of characters in a file. You first want to read these characters from the file in groups of 8. Depending on the specific format of your file (e.g. each set of 8 characters is on its own line, or they're separated by commas, etc.), you could use functions

If I perform a float (single precision) operation on a Host and a Device (GPU arch sm_13) , then will the values be different ? A good discussion of this is availble in a whitepaper from NVIDIA. Basically: IEEE-754 is implemented by almost everything currently; Even between faithful implementation of this standard, you can still see differences in results (famously, Intel's doing 80-bit internally for double precision), or high optimization settings with your compiler can change results Compute capability 2.0 and later NVIDIA cards support IEEE-754 in both single and double precision, with

In my code, float f = -0.0; // Negative and compared with negative zero f == -0.0f result will be true . But float f = 0.0; // Positive and compared with negative zero f == -0.0f also, result will be true instead of false Why in both cases result to be true? Here is a MCVE to test it (live on coliru) : #include <iostream> int main() { float f = -0.0; std::cout<<"==== > " << f <<std::endl<<std::endl; if(f == -0.0f) { std::cout<<"true"<<std::endl; } else { std::cout<<"false"<<std::endl; } } Output: ==== > -0 // Here print negative zero true Floating point arithmetic in C++ is often IEEE-754 .

Let's say I have this: float i = 1.5 in binary, this float is represented as: 0 01111111 10000000000000000000000 I broke up the binary to represent the 'signed', 'exponent' and 'fraction' chunks. What I don't understand is how this represents 1.5. The exponent is 0 once you subtract the bias (127 - 127), and the fraction part with the implicit leading one is 1.1. How does 1.1 scaled by nothing = 1.5??? Think first in terms of decimal (base 10): 643.72 is: (6 * 10 2 ) + (4 * 10 1 ) + (3 * 10 0 ) + (7 * 10 -1 ) + (2 * 10 -2 ) or 600 + 40 + 3 + 7/10 + 2/100. That's because n 0 is always 1, n -1

I have some single and double precision floats that I want to write to and read from a byte[]. Is there anything in .Net I can use to convert them to and from their 32 and 64 bit IEEE 754 representations? .NET Single and Double are already in IEEE-754 format. You can use BitConverter.ToSingle() and ToDouble() to convert byte[] to floating point, GetBytes() to go the other way around. If you don't want to allocate new arrays all the time (which is what GetBytes does), you can use unsafe code to write to a buffer directly: static void Main() { byte[] data = new byte[20]; GetBytes(0, data, 0);