0

I have a question regarding precision of calculations - it is more of a mathematical theory behind programming.

I have a given float number X and the rounding of that number, which is accurate to 10^(-n) decimal place: X'. Now, I would like to know, if after calculating exponent function: y=2^(x) the difference between my number and the rounded number would stay on the same level of precision. I mean:

|2^(X)-2^(X')| is at the level of 10^(-n-1)

Pascal Cuoq
  • 79,187
  • 7
  • 161
  • 281
maciek
  • 1,807
  • 2
  • 18
  • 30
  • The etiquette here is not to sign your questions (your name is in the bottom right). Greetings and thanks should also be avoided. – Pascal Cuoq Apr 25 '15 at 18:35

1 Answers1

2

Exponentiation magnifies relative error and, by extension, ulp error. Consider this illustrative example: 

float x = 0x1.fffffep6;
printf ("x=%a %15.8e  exp2(x)=%a %15.8e\n", x, x, exp2f (x), exp2f(x));
x = nextafterf (x, 0.0f);
printf ("x=%a %15.8e  exp2(x)=%a %15.8e\n", x, x, exp2f (x), exp2f(x));

This will print something like

x=0x1.fffffep+6 1.27999992e+02  exp2(x)=0x1.ffff4ep+127 3.40280562e+38
x=0x1.fffffcp+6 1.27999985e+02  exp2(x)=0x1.fffe9ep+127 3.40278777e+38

The maximum ulp error in the result will be on the same order of magnitude as 2exponent bits of the floating format used. In this particular example, there are 8 exponent bits in an IEEE-754 float, and a 1 ulp difference in the input translates into a 176 ulp difference in the result. The relative difference in the arguments is about 5.5e-8, while the relative difference in the results is about 5.3e-6.

A simplified, intuitive, way of thinking about this magnification is that out of the finite number of bits in the significand / mantissa of the floating-point argument, some only contribute to the magnitude, thus exponent bits, of the result (in the example, these would be the bits representing the integral portion of 127), while the remaining bits contribute to the significand / mantissa bits of the result.

If you look at it mathematically, if the original argument x = n*(1+ε), then ex = en*(1+ε) = en * en*ε ≈ en * (1+n*ε). So if n ≈ 128, ε ≈ 1e-7, then expected maximum relative error is around 1.28e-5.

njuffa
  • 23,970
  • 4
  • 78
  • 130
  • I dont quite understand this... Having to calculate 2^x, while x is a large number with many digits after '.' should I round the results to as far digit as possible ? Would not that increase the order of magnitute of result error, according to what you have written ? – maciek Apr 25 '15 at 21:28
  • I don't understand your question. – njuffa Apr 25 '15 at 21:33
  • What should I do to minimize the error: use more or less exponent bits ? More precision is an intuitive answer, but you have written that the more exponent bits I use the greater the maximum ulp error in the result I get. – maciek Apr 25 '15 at 21:43
  • After you have added the part with "n*(1+ε)" it came quite obvious that the more precise number the better. What have I misinterpreted in your anwer about maximal ulp error in result then ? – maciek Apr 25 '15 at 21:48
  • The magnification of relative error in exponentiation is a function of the magnitude of the argument. The number of exponent bits, which is fixed for any chosen IEEE-754 floating-point format, provides an upper limit on the magnitude of the argument and thus the magnification. I gave a worst case example to illustrate the issue. You have provided no context, so I cannot recommend a strategy. For example, you could try representing the input as a double-double or double-float, and then compute exp(head) + tail * exp(head), which would work well when trying to implement `pow(x,y)`. – njuffa Apr 25 '15 at 21:53
  • I give you sample numbers that couse exponent with the base of 2 to crash (I work in Python): 2299.822 7.91984445946 138447.951506 124.009834527 3.0254885174e+11. In fact I will later calculate the ratio of them and I am interested in 4-5 first digits of the ratio (but I cannot do 2^(a-b), there are same operations on numbers before calculating ratio) – maciek Apr 25 '15 at 22:10
  • @maciek It seems this is getting pretty far away from your original question. I would suggest posting a new question for whatever related follow-up issues you need assistance with. – njuffa Apr 25 '15 at 22:16