Re: powf(float,float) function from math.h on ARM32-bit platform

[Michael Veksler <mveksler at tx dot technion dot ac dot il>]

On 07/30/2013 02:59 PM, hemant wrote:
> I have written a std code for ARM 32-bit platform using math.h library and
> float=powf(float,float) function. When I give input to my system as 100 ^
> 4.4 it gives me answer as 630957632.0000 (as float) whereas calculator in
> WindowsXP gives answer as 630957344.48019324943436013662234.
>
> I just want to know which one is more accurate ????  why is difference ?????
> on what things accuracy depends????
>
> Also what do we mean by "arbitrary"-precision??? I have read such word on
> MSDN help forums.
>
> how much accurate is my system???? how to improve accuracy??????
You should read:
http://en.wikipedia.org/wiki/IEEE_754

The reason is that 4.4 is not accurately represented
in binary. This is like 1/3 which isn't accurately represented
in decimal.

To calculate the impact of this inaccuracy, you need to
consider the structure of float. Float has 23 bits
fraction+one leading '1' bit. This means that  you have
a 24 bit significand. Assuming 'round to nearest'
    error= 4.4* 2.0^{-24}
And the float value is around 4.4+/- error.

I computed this with 'bc' using scale=100 and got
100^(4.4+error)-100^4.4 = 762.0...
100^(4.4-error)-100^4.4 = -762.0...

Before even considering the inaccuracy of assigning
pow's result to float, you get an answer which can be
off by +/- 762.

Also, since pow(b,e) is implemented, as far as I know,
by exp(log(b)*e) you've got 3 operations and not one,
which add up their inaccuracies. So your *theoretical*
accuracy is even lower, much lower since most
inaccuracies are accumulated to the argument of 'exp'.
It's probably around +/-2286.

This explains why you've got a result which is off  by
nearly 300. It could have been much worse.

Michael