I Didn't Find any algorithm related to finv anywhere.
FINV depends on precision of FDIST. FINV uses an iterative search technique. If the search has not converged after 100 iterations, the function returns the #N/A error value.
now i dont know how to do these iterations using FDIST?
I've a problem with the proper conversion of double to it's string representation.
If I've in the code some double value:
double a = 69000.015;
the debugger in debug window will show 69000.014999999999 but not 69000.015
Generally I need the precision and number of significant digits for the conversion.
For sprintf(...) I have to specify the precision and specifier.
How can I get the correct precision of the double value?
Is there any solution/clases for this type of conversion?
there is simply no solution to your problem. Floating point numbers, by their very nature, cannot always represent the intended value.
The simplest example is the outcome of 1.0/3.0
humans write it down as 0.333333..., computers perform the division in binary and get a reasonably
accurate quotient (say off by no more than 1 of the lowest bit position), which is after all
The binary approximation of 1/3 is something like 1/4 + 1/16 + 1/64 + 1/256 + ...
and it has to stop somewhere since there are only so many bits reserved for the mantissa.
Similar things will happen to almost all real numbers; in order to avoid it, the number must
happen to be an integer value possibly divided by a power of two.
Hence 1.0/4.0, 7.0/4.0, 23.0/256.0 etc can be represented exactly,
whereas numbers with a prime factor (other than 2) in the denominator will not be exact,
nor will irrational numbers (such as pi, or the square root of 2).
If you know how many decimals (i.e. digits behind the decimal point) are required to get an exact
representation, then order that number of decimals or fewer. Rounding will occur, and everything
will look very natural.
If you don't know the number of decimals required and care very much about the correctness of them,
say you start your own financial program or business, then you'd better have a look at the decimal type. It offers a smaller range of numbers, but in some sense a better accuracy.
Thanks Luc for the answer,
but unfortunally I'm not a Fortran developer, I do Visual C++ which do not have a decimal type.
But the 69000.015 is non preiodical double(not like 1/3=0.333333...) and internal CPU's data register representation will be a particular correspondent binary. I'm not a pro in math, but for me seems like it needs some analysis of the binary representation to get a precision.
This page [^]may show the internal representation of a decimal number as double.
It comes out, that 69000.015 is represented with 40F0D8803D70A3D,
i.e. 1.0528566741943360 as significand and 16 as exponent.
If you put the above number in windows calculator then you'll get: