about accuracy of the estimations

[keremusu1]

Hello!

1. How can I increase the number of decimals of the calculated variablesto increase the accuracy of the final estimation which depends on these variables.

2.How can I introduce the number E22 (10**22) to the fortran source code. I tried to write as n=E22 but ithas taken it as 0.Should I increase the number of digits that is taken into account or what?

Thanks.

[TimP]

1. It's not clear whether you mean increasing precision from default, e.g.
real(selected_real_kind(12)) :: a
2. It looks like you meant something like
real :: n=1e22
The 1 isn't optional, and you will run into trouble if you don't declare data types.
If your textbook or online tutorial doesn't explain these questions, several better ones are available.

[keremusu1]

Where can I find these online tutorials. Can you please give me the URLs.

[jimdempseyatthecove]

Keremusu,

Floating point literals (constants) are generally converted from the source file into binary code using the default floating point precision. This is generally REAL(4). You can override this behavior (as shown by the example on your other thread) by various means.

10E22generally a REAL(4)
10E22_8explicitly REAL(8)

Look at the documentation under double precision constants.

Jim Dempsey

[Steven_L_Intel1]

True, but even REAL(8) isn't going to help with a number as large as 10E22 - not enough bits in the binary fraction.

[jimdempseyatthecove]

Steve,

>> True, but even REAL(8) isn't going to help with a number as large as 10E22 - not enough bits in the binary fraction.

Yes. I may take more than 53 bits to express that number.

However, that said. If his original huge data array has meaningful data, each expressible within 53 bits of mantissa, but where the full range of bits required could be over 100 bits of mantissa, reasonably better summation estimates can be attained by adding numbers within the array that have similar magnitudes. In this manner the LSBs of the small value numbers are not shifted out when added to a large value number (at least until the last step in the summation). The code I listed might be inadequite but certainly could be expanded upon. The final result would still be 53 bits but the summation loop could easily be expanded to produce a better number

Jim