ieee-754

I realize that whenever one is dealing with IEEE 754 doubles and floats, some numbers can't be represented especially when one tries to represent numbers with lots of digits after the decimal point. This is well understood but I was curious if there were any whole numbers within the MIN/MAX range of a double (or float) that couldn't be represented and thus needed to be rounded to the nearest representable IEEE 754 representation? For instance very large numbers are sometimes represented in doubles or floats even if they are whole numbers. Clearly using a straight up int64 or some such large

Is IEEE-754 arithmetic reproducible on different platforms? I was testing some code written in R, that uses random numbers. I thought that setting the seed of the random number generator on all tested platforms would make the tests reproducible, but this does not seem to be true for rexp() , which generates exponentially distributed random numbers. This is what I get on 32 bit Linux: options(digits=22) ; set.seed(9) ; rexp(1, 5) # [1] 0.2806184054728815824298 sessionInfo() # R version 3.0.2 (2013-09-25) # Platform: i686-pc-linux-gnu (32-bit) and this is what I get on 64 bit OSX 10.9: options

I guess another way of phrasing this question is what decimal place can you go to using a float that will only be between 0 and 1? I've tried to work it out by looking at the MSDN . Which says the precision is 7 digits. I thought that meant it could only track changes of 0.0000001 . However if I do: float test = 0.00000000000000000000000000000000000000000001f; Console.WriteLine(test); It writes out 9.949219E-44 If I add any more zeroes, it will output 0 . I'm pretty sure I'm missing something here as that degree of accuracy seems massively wrong. Mainly as a float is 32bits in size, and just

My method is as follows def myMethod(myDouble: Double): Double = myDouble match { case Double.NaN => ... case _ => ... } The IntelliJ debugger is showing NaN but this is not being picked up in my pattern matching. Are there possible cases I am omitting It is a general rule how 64-bit floating point numbers are compared according to IEEE 754 (not Scala or even Java related, see NaN ): double n1 = Double.NaN; double n2 = Double.NaN; System.out.println(n1 == n2); //false The idea is that NaN is a marker value for unknown or indeterminate . Comparing two unknown values should always yields false

What's the easiest way to convert a floating point number to its binary representation in Javascript? (e.g. 1.0 -> 0x3F800000). I have tried to do it manually, and this works to some extent (with usual numbers), but it fails for very big or very small numbers (no range checking) and for special cases (NaN, infinity, etc.): function floatToNumber(flt) { var sign = (flt < 0) ? 1 : 0; flt = Math.abs(flt); var exponent = Math.floor(Math.log(flt) / Math.LN2); var mantissa = flt / Math.pow(2, exponent); return (sign << 31) | ((exponent + 127) << 23) | ((mantissa * Math.pow(2, 23)) & 0x7FFFFF); } Am

In most cases, I understand that a floating point comparison test should be implemented using over a range of values (abs(x-y) < epsilon), but does self subtraction imply that the result will be zero? // can the assertion be triggered? float x = //?; assert( x-x == 0 ) My guess is that nan/inf might be special cases, but I'm more interested in what happens for simple values. edit: I'm happy to pick an answer if someone can cite a reference (IEEE floating point standard)? As you hinted, inf - inf is NaN , which is not equal to zero. Similarly, NaN - NaN is NaN . It is true, however, that for

Is it possible to get division by 0 (or infinity) in the following example? public double calculation(double a, double b) { if (a == b) { return 0; } else { return 2 / (a - b); } } In normal cases it will not, of course. But what if a and b are very close, can (a-b) result in being 0 due to precision of the calculation? Note that this question is for Java, but I think it will apply to most programming languages. nwellnhof In Java, a - b is never equal to 0 if a != b . This is because Java mandates IEEE 754 floating point operations which support denormalized numbers. From the spec : In