forums.silverfrost.com

Konstantin8 · Joined: 07 Jun 2013 Posts: 9

Sorry for this question but unfortunately I cannot find any "clear" information...
Is there any ability to work with extended precision (real*10)?

I wrote the following:
real*10 A

then I try to use sqrt for A.

But unfortunately it's not possible.

Could anybody give me an advice? Smile

Thanks!

JohnCampbell · Joined: 16 Feb 2006 Posts: 2621 Location: Sydney

The following simple code works ok for me

Konstantin8 · Joined: 07 Jun 2013 Posts: 9

JohnCampbell · Joined: 16 Feb 2006 Posts: 2621 Location: Sydney

The following code might better demonstrate the precision of the alternative real kinds available in ftn95

DanRRight · Posted: Thu Jun 13, 2013 3:24 pm Post subject:

I had the code waiting for extended precision for ages and i gave it a try today.

Just for info, the machine ESP for real*10 is in the region of 5*10^-20 which can be taken from this simple code

PaulLaidler · Posted: Thu Jun 13, 2013 3:58 pm Post subject:

If you declare REAL(3)::x then the compiler will provide a useful comment to tell you what to use in place of 3.

DanRRight · Posted: Thu Jun 13, 2013 4:55 pm Post subject:

Thanks. I also found something relevant in the Help, but will this fix the error i've got?

PaulLaidler · Posted: Thu Jun 13, 2013 5:20 pm Post subject:

I don't think so. You will need to write code that avoids overflow.
You can probably trap the exception if it occurs at run time but I don't see how that will help.

DanRRight · Posted: Thu Jun 13, 2013 5:23 pm Post subject:

But that is not an error and not an under/overflow! This is completely legitimate code which got these kind of too large or too small numbers due to tricky method of solution! And these sort of crazy numbers were in the FP coprocessors since IBM PC XT, we just never used them because compilers did not allow that

PaulLaidler · Posted: Thu Jun 13, 2013 5:29 pm Post subject:

Maybe you should use constants with the corresponding KIND.

e.g. x = 1.0_3

DanRRight · Posted: Thu Jun 13, 2013 5:44 pm Post subject:

Alas, compiler still gives an error that floating point number out of rangeBad value for exponent. I suspect the limit in compiler is done for real*8 numbers and is explicitly wired somewhere in the source

JohnCampbell · Joined: 16 Feb 2006 Posts: 2621 Location: Sydney

Dan,

I'd like to see the example which fails with bad exponent value, including declarations.
I think you have to be careful with constant definition, to ensure the implied precision. The following example code fails for the last two lines, but the previous 3 do work.

PaulLaidler · Posted: Fri Jun 14, 2013 6:57 am Post subject:

x = 1d400 fails but x = 1e400_3 is OK.

DanRRight · Posted: Fri Jun 14, 2013 12:54 pm Post subject:

Thanks John and Paul. So

if(aa.gt.2e-4000_3) write(*,*) 'something'

works but

if(aa.gt.2d-4000_3) write(*,*) 'something'

DOES NOT work!? THAT....that...that's TOTALLY counterintuitive!

And inconvenient. When you program you adjust the value of constant and use E till 10^37, then you use D till 10^309 and then again E??? Inconvenient, confusing, counterintuitive. That will end up with the loss of the whole day for any programmer in future. Or more, because i have got this forum and the pros here, others may lose much more than that. Is this how Standard precludes to do that? If these letter serve as a switch for different implementations of the intrinsic functions when you change precision then for extended precision Standard should allow all three different letters E (for "exponent'), D(from 'Double precision') and, say, X for "extended precision'! Or at least compiler should give the diagnostics and recommendation (giving recommendation would be next good thing for future Fortran compilers)

PaulLaidler · Posted: Fri Jun 14, 2013 3:10 pm Post subject:

I guess that the D is for double precision so in FTN95 D is equivalent to E with _2 as the KIND.