ieee-754

I'm performing some data type conversions where I need to represent uint , long , ulong and decimal as IEEE 754 double floating point values. I want to be able to detect if the IEEE 754 data type cannot contain the value before I perform the conversion. A brute force solution would be to wrap a try-catch around a cast to double looking for OverflowException . Reading through certain of the CLR documentation implies that some conversions just silently change the value without any exceptions. Is there any fool proof way to do this check? I'm looking for completeness over ease of implementation.

Why does the following code behave as it does in C? float x = 2147483647; //2^31 printf("%f\n", x); //Outputs 2147483648 Here is my thought process: 2147483647 = 0 1001 1101 1111 1111 1111 1111 1111 111 (0.11111111111111111111111)base2 = (1-(0.5)^23)base10 => (1.11111111111111111111111)base2 = (1 + 1-(0.5)^23)base10 = (1.99999988)base10 Therefore, to convert the IEEE 754 notation back to decimal: 1.99999988 * 2^30 = 2147483520 So technically, the C program must have printed out 2147483520, right? The value to be represented would be 2147483647. the next two values which can be represented this

How can I read the raw bytes of a Float or Double in Swift? Example: let x = Float(1.5) let bytes1: UInt32 = getRawBytes(x) let bytes2: UInt32 = 0b00111111110000000000000000000000 I want bytes1 and bytes2 to contain the same value, since this binary number is the Float representation of 1.5 . I need it to do bit-wise operations like & and >> (these are not defined on a float). Update for Swift 3: As of Swift 3, all floating point types have bitPattern property which returns an unsigned integer with the same memory representation, and a corresponding init(bitPattern:) constructor for the

If have an 8-byte section of data and write a double-precision floating-point value to it, under what conditions will comparison by numerical comparison and lexicographic sorting of the bytes agree? Current theory: positive, big-endian I believe that if the number is positive, and the representation is big-endian, then numerical ordering of the floating-point values will match the lexicographic ordering of the bytes. The idea is that it would first sort on the exponent, then on the mantissa. Even the "denormalized" IEEE representation shouldn't cause any problems. Is this true? (I'm using Node

Is something broken or I fail to understand what is happening? static String getRealBinary(double val) { long tmp = Double.doubleToLongBits(val); StringBuilder sb = new StringBuilder(); for (long n = 64; --n > 0; tmp >>= 1) if ((tmp & 1) == 0) sb.insert(0, ('0')); else sb.insert(0, ('1')); sb.insert(0, '[').insert(2, "] [").insert(16, "] [").append(']'); return sb.toString(); } public static void main(String[] argv) { for (int j = 3; --j >= 0;) { double d = j; for (int i = 3; --i >= 0;) { d += Double.MIN_VALUE; System.out.println(d +getRealBinary(d)); } } } With output: 2.0[1] [00000000000]

According to the IEEE floating point wikipage (on IEEE 754), there is a total order on double-precision floating points (i.e. on C++11 implementations having IEEE-754 floats, like gcc 4.8 on Linux / x86-64). Of course, operator < on double is often providing a total order, but NaN are known to be exceptions (it is well known folklore that x != x is a way of testing if x , declared as double x; is a NaN). The reason I am asking is that I want to have a.g. std::set<double> (actually, a set of JSON-like -or Python like- values) and I would like the set to have some canonical representation (my